idnits 2.17.1 draft-lendl-speermint-background-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1015. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1026. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1039. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2008) is 5652 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '5') (Obsoleted by RFC 8224) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Speermint Working Group O. Lendl 3 Internet-Draft enum.at 4 Intended status: Informational October 28, 2008 5 Expires: May 1, 2009 7 VoIP Peering: Background and Assumptions 8 draft-lendl-speermint-background-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 1, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This documents provides background for the work on VoIP peering and 42 tries to provide guidance on what kind of work is needed to 43 facilitate widespread SIP-based peering of telephony networks. It is 44 intended to spur discussion on the work about peering (in the 45 SPEERMINT and DRINKS WGs) and should also serve as input to the 46 ongoing discussions on reducing Spam for Internet Telephony (SPIT). 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Interconnection Models . . . . . . . . . . . . . . . . . . . . 4 53 2.1. The PSTN model . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. The email model . . . . . . . . . . . . . . . . . . . . . 5 56 3. Why is SPEERMINT needed? . . . . . . . . . . . . . . . . . . . 6 57 3.1. Why did the Email Model fail for SIP? . . . . . . . . . . 6 58 3.2. The PSTN Model does not fit, either . . . . . . . . . . . 9 60 4. Core Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10 61 4.1. The Real Problem with SPIT . . . . . . . . . . . . . . . . 10 62 4.2. What is a SIP URI? . . . . . . . . . . . . . . . . . . . . 11 63 4.3. Peering vs. Reachability . . . . . . . . . . . . . . . . . 11 64 4.4. The Key to Routing Data . . . . . . . . . . . . . . . . . 12 65 4.5. Lookups vs. Announcements . . . . . . . . . . . . . . . . 12 66 4.6. No National Solutions . . . . . . . . . . . . . . . . . . 14 68 5. A Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 5.1. The Players . . . . . . . . . . . . . . . . . . . . . . . 15 70 5.2. Interconnection fabrics . . . . . . . . . . . . . . . . . 15 71 5.2.1. Old-style TDM based interconnection . . . . . . . . . 15 72 5.2.2. Private SIP interconnection . . . . . . . . . . . . . 15 73 5.2.3. Commercial Peering Fabrics . . . . . . . . . . . . . . 16 74 5.2.4. Overlay networks . . . . . . . . . . . . . . . . . . . 16 75 5.2.5. RFC3263-style SIP . . . . . . . . . . . . . . . . . . 16 76 5.3. An internet of Voice Networks . . . . . . . . . . . . . . 16 77 5.4. The Lookup Function (LUF) . . . . . . . . . . . . . . . . 16 78 5.5. The Location Routing Function (LRF) . . . . . . . . . . . 17 80 6. Design Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.1. Reliance on fabric internals for multi-hop routing . . . . 19 82 6.2. Mistaking a protocol for softswitch/SBE control for 83 LUF/LRF . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 6.3. Mixing LUF and LRF . . . . . . . . . . . . . . . . . . . . 20 85 6.4. Provisioning vs. routing . . . . . . . . . . . . . . . . . 20 86 6.5. RFC 3263 is part of the problem . . . . . . . . . . . . . 21 87 6.6. Disregarding enterprises . . . . . . . . . . . . . . . . . 21 89 7. What building-blocks are missing? . . . . . . . . . . . . . . 21 90 7.1. LUF / I-ENUM provisioning . . . . . . . . . . . . . . . . 21 91 7.2. LRF Routing announcements . . . . . . . . . . . . . . . . 21 92 7.3. A call-control protocol . . . . . . . . . . . . . . . . . 21 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 Intellectual Property and Copyright Statements . . . . . . . . . . 24 106 1. Introduction 108 The Speermint WG is chartered to help with the interconnection of SIP 109 based layer 7 networks. It should not deal with basic IP 110 connectivity and SIP protocol issues; those are covered by other 111 working groups. 113 Speermint focuses on what guidelines (and perhaps protocol elements) 114 are needed by service providers and enterprises to move from ad-hoc, 115 manual peerings to a fully standardized, secure, easy to implement, 116 and thus widespread SIP based peering setup. 118 This document aims solely at the telephony network aspects of SIP and 119 ignores applications like Instant Messaging or Presence which might 120 also be implemented using SIP. The focus here is on the use of SIP 121 in PSTN replacement services. 123 Version -01 of this draft expands on the implications of the 124 interconnection structure on the SPIT problem. The concepts listed 125 in here should thus also be worthwhile for the RUCUS EG. 127 Version -02 of this draft provides a rough overview on how the voice 128 interconnection landscape might look like in the future and lists 129 specific work items for the SPEERMINT and DRINKS WGs. 131 This document was written as discussion input. It is not intended 132 for publication as an RFC. 134 2. Interconnection Models 136 In order to understand the VoIP peering world it is necessary to go 137 beyond pure protocol issues and instead talk about the ecosystems in 138 which the protocols operate. This section tries to be purely 139 descriptive and makes no recommendations. 141 2.1. The PSTN model 143 The public switched telephone network (PSTN) is built upon the 144 following fundamental assumptions: 146 o When the system was designed, the numbers of operators was 147 limited. Often, there was just a single incumbent per country. 148 Building a full mesh for international interconnection was 149 possible. This is no longer true. 151 o Global reachability is achieved by interconnecting individual 152 smaller networks. There is no global lower-layer connectivity: if 153 two networks are not directly interconnected, then calls are 154 passed through transit networks on the application layer. 156 o There are no ad-hoc connections between networks: all links are 157 manually configured lines (physical, or other transparent bit- 158 pipes). 160 o There is a clear separation between network operators and network 161 users. This applies both to protocols (e.g., SS7 ISUP versus 162 ISDN), as well as, to regulatory rules. 164 o Routing information is not directly passed from the destination 165 network to the source network via some global database. Instead, 166 transit networks communicate to their customers which destinations 167 they can handle. 169 o Accounting and settlement are core features. 171 2.2. The email model 173 SIP according to RFC 3261 [2] and RFC 3263 [3] follows an email alike 174 model. It can be summarized as follows: 176 o Email and SIP addresses are structured as username@domain. For 177 routing purposes, only the domain part is relevant. The username 178 is only interpreted by the machines serving this specific domain. 180 o The global, public DNS is used to map the domain from the address 181 to a prioritized set of ingress points that handle incoming 182 communication requests for this domain. As the DNS is agnostic to 183 the entity querying data stored there, all senders receive the 184 same set of ingress points. 186 o In order to achieve global reachability, these ingress points need 187 to accept incoming requests from the open Internet. If they 188 reject, for example, incoming packets from a VoIP provider X from 189 country Y then there is no backup path for this communication, and 190 the destination just will not be reachable from that VoIP provider 191 X. 193 o As anybody on the Internet can contact any destination domain, no 194 business relationship between sender and destination domain is 195 required. This implies that there is no settlement: No money is 196 changing hands because of such a communication. 198 o There is no inherent distinction between end users and service 199 providers hard-coded into the protocol. Any client can do the DNS 200 lookups himself and directly contact the destination servers. 202 o Usually clients do not talk directly to each other: On the source 203 side a SIP INVITE is forwarded to the outbound proxy that applies 204 the routing algorithm, which then contacts its peer on the 205 destination side that also performs additional processing before 206 handing off the communication to the destination side. 208 The email model has proved to be extremely successful -- for email. 210 3. Why is SPEERMINT needed? 212 In theory, the Speermint WG is not necessary: The SIP RFCs envision 213 global reachability of all SIP devices over the public Internet. 214 Source networks just need to resolve the domain from the URI 215 according to RFC 3263 and send the INVITE to the SIP proxy in charge 216 of that destination domain. 218 Telephone number (TN) based calling is also supported: RFC 3761 [1] 219 provides TN to URI mapping and thus reduces the call routing problem 220 to the already solved case of SIP URI resolution. 222 * Apparently, the real world did not choose to implement and deploy 223 SIP and public ENUM as initially envisioned by their inventors. In 224 other words: the motivation for Speermint is the failure of the world 225 to conform to the original IETF vision of SIP based real-time 226 communication. * 228 3.1. Why did the Email Model fail for SIP? 230 Although SIP has won the protocol war against H.323 (just as SMTP won 231 against X.400), it failed to establish the same sort of ecosystem in 232 the Internet as SMTP was able to do. The number of SIP users who are 233 reachable via the open Internet using RFC 3263 is minuscule compared 234 to the number of SIP based telephones in operation today. 236 SIP as a protocol has succeeded; SIP as an ecosystem similar to SMTP 237 has failed. 239 The need for Speermint arises from that failure: SIP has seen 240 widespread deployment within enterprises and service providers, but 241 the inter-connection part of SIP has not: current deployments usually 242 do not follow RFC 3263, but use either hard-coded IP addresses or 243 private DNS to route calls between SSPs, if they use SIP at all and 244 not the PSTN. 246 The same applies to ENUM according to RFC 3761: The technology has 247 been successful (as the large number of private ENUM trees 248 demonstrates), but the original vision of ENUM proved to be elusive: 249 the "golden tree" under e164.arpa contains a fraction of entries 250 compared to the numbers found in private trees. 252 Speermint is chartered to provide solutions for the interconnection 253 problem. It is thus essential to examine why the current standards 254 have failed. Without this gap-analysis there is little chance that 255 Speermint will come up with the missing pieces. 257 As mentioned before, this analysis cannot be restricted to pure 258 technological aspects, and will thus touch on the business models 259 implied by the technical standards. It is the firm believe of the 260 author that the IETF credo "we don't do business models" has been 261 implicitly violated by existing standards. One approach is thus to 262 identify these implications and augment the protocols to allow them 263 to support a varity of business models and ecosystems. 265 Business Model 267 The email model hard-codes a "sender-keeps-all" settlement regime. 268 As anybody is able to connect to anybody, no business relationship 269 is needed between communication partners. Thus, no termination 270 fees can be collected. 272 The economic model of the current carrier landscape in most 273 countries depends on these charges, and it just does not make 274 sense for any single carrier to allow anonymous incoming SIP-based 275 interconnection as that means lost income. If call patterns are 276 about symmetrical, switching to sender-keeps-all is revenue- 277 neutral for all carriers. There is no clear path on how such a 278 fundamental shift in the bedrock of telco settlement could happen. 279 (other than by regulatory fiat) 281 The end-state might be a viable business model, but there is no 282 incentive for any individual SSP to start the transition. 284 This argument applies only to SSPs that are substitutes for PSTN 285 carriers, and not to enterprises operating a SIP infrastructure. 287 Unwanted Calls 289 Spam over Internet Telephony (SPIT) is another concern. The free 290 for all nature of the email ecosystem has led to a barrage of 291 unsolicited email (SPAM) which poses a serious threat to the 292 usefulness of email. 294 Email is non-interactive: filters can be deployed to detect spam 295 by the content of the mail before the recipient is alerted. That 296 is not possible for SPIT; content is only available after the 297 recipient has picked up the phone. A number of SPIT mitigation 298 strategies have been proposed over the past few years, their 299 effectiveness is yet untested. See also [6]. 301 As of 2008, SPIT is not a problem, mainly because the number of 302 open reachable SIP devices is so low. Just as SPAM only started 303 to become a problem after open SMTP servers became common, many 304 SSPs fear that SPIT will appear if they open up their networks. 306 Identity 308 Traditional telecom services provide reasonably reliable caller 309 identification. Telcos trust each other's signaling and end users 310 have learned to trust caller-id (even if this trust is somewhat 311 unjustified). Such a trust model is not compatible with the email 312 model of open SIP servers: the INVITE message can come from any 313 host on the Internet and is thus not trusted. 315 Providing a reliable caller identification is also important for 316 policing: Harassing and abusive calls are more or less under 317 control, as legal and contractual rules can be enforced by tracing 318 calls back to the culprit. 320 SIP Identity (RFC 4474 [5]) uses a different approach that is 321 based on an authentication service cryptographically asserting the 322 identity of the caller. As such, it is different to the current 323 practice in the telco space, which is based on transitive trust. 325 QoS and Denial of Service 327 The email model is not suitable for stringent Quality of Service 328 (QoS) deployments. As there are no pre-arranged relationships 329 with between all communicating SIP servers, there are no 330 mechanisms to guarantee neither network performance on the IP 331 layer for the actual voice transmission, nor can there be 332 comprehensive tests on SIP layer compatibility. 334 As the ingress points need to be open to anybody on the Internet, 335 they are exposed to Denial of Service attacks. 337 This combination is at odds with the telco mind-set that thrives 338 on predictable quality and stringent service level guarantees. 340 Legal Requirements 342 Operators of public telephony services need to observe a range of 343 regulatory requirements. These rules were written for the PSTN 344 scenario with clearly defined boundaries between operators and 345 users of the telephone network. Changing the interconnection 346 model make these regulations a bad fit for the email model. 348 For example, if the user requests CLIR (Calling Line 349 Identification Restriction) then its SSPs needs to differentiate 350 the call handling, whether the peering partner is another 351 commercial SSPs (transmit caller-ID, signal CLIR) or an enterprise 352 (suppress caller-ID). Interconnecting with other SSPs that 353 operate under the same rules simplifies compliance. 355 3.2. The PSTN Model does not fit, either 357 It is of course possible to rebuild the PSTN based on SIP instead of 358 SS7. Some might argue that this is what the IMS and NGN efforts are 359 all about. This is selling SIP and the Internet short: The basic 360 infrastructure that the Internet offers allows for far more flexible 361 interconnection arrangements than a simple copy of the PSTN 362 structure. 364 Shared Layer 3 Infrastructure 366 The PSTN is based on trunk lines connecting voice switches. These 367 trunks are manually established between carriers. Each such link 368 needs physical ports, as well as, dedicated bandwidth. 369 Establishing direct links between carriers is thus only sensible 370 if call volumes can justify the effort. 372 In contrast to the point-to-point link world of the PSTN, SIP 373 assumes an any-to-any IP based communication model. This has a 374 profound impact on the economics of interconnection: A new peering 375 is not a matter of provisioning a new bit-pipe, but just one of 376 configuring border elements on both sides. 378 Economic theory states that there must be a optimal number of 379 peerings per SSP given the costs to establish an interconnection 380 versus the costs of transit. As the cost structure is 381 fundamentally different, the mesh density of the optimal SIP based 382 network will deviate significantly from the current PSTN. 384 Enterprise Peering 386 As a corollary: Peering between TDM-based enterprise telephony 387 systems is usually limited to very high traffic cross-links. As 388 enterprise-to-enterprise calls do not require settlement, there is 389 a huge potential for additional peering in this space. 391 Dynamic Routing 393 Worldwide routing in the PSTN is still based mainly on manually 394 established routes; these routes reflect business relationships. 395 As a consequence, it takes years to a get a new number range 396 routed in the PSTN. The switch from SS7 to SIP must be taken as a 397 chance to upgrade the worldwide call routing to a better routing 398 algorithm. 400 4. Core Assumptions 402 The author believes that some working assumptions have to be re- 403 thought based on the feedback from current deployment. 405 4.1. The Real Problem with SPIT 407 SPIT and QoS/DoS issues have often been cited as reason why so few 408 people (enterprises and commercial SSPs) run an open SIP service 409 (i.e. accept SIP calls from the public Internet without pre- 410 association). The IETF has taken on the challenge and tried to 411 develop protocol extensions that should help with the SIP adoption. 412 These are often based on the following reasoning: 414 +------------+ +-------------+ +-------------+ 415 |We want to | |They need to | |They have a | 416 |interconnect|===(1)===>|run open |===(2)===>|problem with | 417 |SSPs | |SIP servers | |SPIT and DoS.| 418 +------------+ +-------------+ +-------------+ 420 A lot of time has been spent on step (2). Protocols and procedures 421 have been proposed to mitigate the exposure of open SIP proxies. 422 These include the consent framework for SIP, SPIT identification, 423 anti-SPIT policy rules, the Identity: header, etc. 425 These are all worthwhile proposals that solve certain symptoms. 426 Regrettably, they do not remove the roadblocks to widespread SIP- 427 based peering. For that, they tackle the wrong set of problems. 428 They assume that the email model can be successful and we just need 429 to make sure that all the associated problems are addressed. 431 This assumption is wrong. The author believes that it is necessary 432 to tackle step (1) first. 434 The question therefore should not be "How do we deal with the 435 unpleasant side effects of universal peering?", but "How can we get 436 SSPs to peer at all?". Instead of "How to keep out the unwanted 437 calls?" we should focus on "How can we entice willing partners to a 438 peering?". 440 4.2. What is a SIP URI? 442 SIP URIs are used in various contexts: They can specify contact 443 points (sip:user@10.0.0.1), they can specify next hop information in 444 a private interconnection setting 445 (sip:012345678@sbc1.chicago.us.example.net), and they can be public 446 SIP URIs (sip:alice@example.com) for which the responsible SIP proxy 447 can be determined using RFC 3263. 449 There is yet another interpretation of the SIP URI that may be 450 relevant for Speermint: The URI as a simple identifier of a telephony 451 customer without the commonly implied semantic on how that user can 452 be contacted. 454 While that is close to the public URI, the difference is important: 455 RFC 3263 does not apply. There is no simple, globally valid set of 456 ingress points for calls towards that URI. The default SIP call 457 routing logic just is not applicable to such URIs. 459 In other words: It is a very useful concept to use the SIP protocol 460 and the URIs from RFC 3261 without also adopting RFC 3263, because 461 the latter more or less implies the email model that has not seen a 462 lot of deployment yet. It is thus expected that any SIP URI 463 published in a public infrastructure ENUM will not imply the 464 applicability of RFC 3263. 466 In order to place calls, some alternative to RFC 3263 needs to be 467 developed that accommodates the needs of carriers. 469 4.3. Peering vs. Reachability 471 Whatever the interconnection setup, subscribers of a telephony 472 service expect to be able to call all subscribes of all other SSPs. 473 When the email model cannot be assumed, this requires the use of 474 transit networks and thus some sort of routing mechanism to find a 475 path to the destination SSP. 477 4.4. The Key to Routing Data 479 Currently, the PSTN side is using telephone numbers (TN) as the key 480 to the routing information, whereas the RFC 3263 SIP uses the domain 481 name. 483 The TN used to be the perfect identifier for routing as the 484 hierarchical structure of the number corresponded to the network 485 topology in the PSTN. The emergence of alternative carriers, number 486 porting, and service numbers (free-phone, premium rate, ...) changed 487 that: This is a form of "locator" / "identifier" split. 489 Prefix-based routing used to be the way to aggregate routes to 490 telephone numbers in order to keep the routing tables and their 491 updates manageable. While that is still useful to encode policies 492 like "Route all of +43 to Carrier XYZ", within a country number 493 portability made prefix-based routing increasingly inefficient. 495 Looking at the routing information from a database design point of 496 view, it does not make sense to store the set of possible routes 497 (incl. all meta-data like prices, capacity, quality,...) for every 498 individual number, as these will be identical for at least all 499 numbers operated by a single carrier in some area. 501 Any routing protocol will thus scale by several orders of magnitude 502 better if it is based on some sort of "Destination-Group" that 503 comprises a carrier identification plus optionally a service or 504 region-specific tag. 506 While the telephone number is the starting point of the routing 507 information lookup, it is not a good identifier to use as the key for 508 storing routes. 510 4.5. Lookups vs. Announcements 512 Generally speaking, there are two ways how to distribute routing 513 information: 515 On Demand 517 Whenever routing information is needed some external database is 518 queried. 520 Example: DNS (including ENUM) 522 Pro-active Distribution 524 The information for all possible destinations is distributed 525 before the first routing decision is made. 527 Example: BGP, OSPF 529 There are of mixed models as well, e.g., when an organization gathers 530 routing information pro-actively to load an internal database that is 531 then queried on an "on-demand" basis by network elements. 532 Alternatively, some systems might pro-actively fetch the fraction of 533 the global routing information covering the most likely destinations, 534 and only fall back to on-demand queries for the rest. 536 The on-demand model requires a lower level transport infrastructure 537 to contact the external database. It's thus clear that Layer 3 538 routing cannot use that model as this leads to a chicken-and-egg 539 problem. However, for VoIP peering basic Internet connectivity can 540 be assumed and the same constraints do not apply. 542 The pro-active model on the other hand operates under a different 543 constraint: Distributing all information needed for the routing 544 decisions to all carriers requires that the aggregate dataset size of 545 these routing information tables does not exceed sensible size 546 limits. For example, it is not feasible to replace the MX record 547 lookup of mail-servers by a routing protocol which replicates the 548 domain-name to mail-server mapping information to all ISPs and 549 enterprise mail-servers. There are just too many domains in use and 550 thus the "mail-routing tables" would exceed all practical limits. 552 With regards to TN based calls, both options are possible. ENUM 553 according to RFC 3761 is a clear on-demand approach. On the PSTN 554 side, downloads of database dumps are a common method to distribute 555 routing information. 557 A scalable routing system is needed, up to the set of all active TN. 558 They number in the billions. Installing a "full routing table" into 559 a core telephony (soft-)switch is thus not feasible. Current PSTN 560 implementations cope by crude aggregation of routes to foreign 561 countries. 563 The number of reachable IP addresses is roughly of the same order of 564 magnitude, but the aggregation properties of IP addresses reduces to 565 global routing table to under 500000 entries without any impact on 566 the quality of the routing decisions. Telephone numbers do not 567 aggregate as well and therefore makes a TN-based protocol in the 568 style of BGP infeasible (that is one reason why TRIP [4] failed). 570 The obvious solution is to add an on-demand mapping step ahead of the 571 routing protocol. That on-demand mapping should include the option 572 to seed a cache with the most likely destination TNs. 574 4.6. No National Solutions 576 Telecom regulation, especially concerning number assignments and 577 interconnection rules, is a national matter. Calling patterns favor 578 local destinations: local and national calls make up the majority of 579 all calls. It is thus not surprising that number based PSTN (and 580 some of the emerging VoIP-based) routing exchanges only deal with 581 numbers from a single country code. 583 On the other hand, international voice termination markets deal 584 usually not with individual numbers, but with routes to number 585 prefixes. 587 Given the increasingly international footprint of voice operators the 588 country-specific ways of handling inter-carrier routing is an 589 anachronism. Just as the Internet routing does not care about 590 national borders, there is no inherent reason why a single set of TN 591 mapping and voice routing protocols cannot be seamlessly deployed in 592 an international setting. There should be no need for special 593 handling per country-code in the routing logic. 595 Consider the case of a pan-European mobile operator Foo. If Foo has 596 signed a peering agreement with a local Austrian VoIP operator Bar, 597 then Bar should pass all calls over this link that terminate in any 598 GSM network that Foo operates. Ideally, Bar should notice when a 599 number was ported to Foo's network in Germany and adapt the routing. 600 If Foo acquires a new network in, say Bulgaria, then Bar should 601 automatically route all calls to that set of numbers over the peering 602 with Foo. All this should happen without Bar having to participate in 603 Germany- or Bulgaria-specific TN database exchanges. 605 All this has been standard in Internet-based communication: both BGP, 606 as well as, application layer protocols like SMTP or HTTP do not care 607 about national borders. The protocol to resolve a .com name is the 608 same as the one to resolve a domain under .cn. BGP speakers announce 609 routes without any regard for national borders. Speermint should 610 strive to achieve the same level of universality. 612 This does not preclude local optimizations. For example, if the 613 mapping from TN to some sort of routing identifier is done by 614 Infrastructure ENUM, then it makes sense to pro-actively prime the 615 SSP name-servers with the data for all local numbers. 617 5. A Vision 619 This section provides a "view from 20,000 feet" on how the 620 interconnection of voice networks might look like in the future. 622 5.1. The Players 624 Historically, voice interconnection used to be the domain of 625 commercial voice network operators. Direct interconnection between 626 corporate PBX systems was the exception as such links required 627 dedicated circuits. With the move to IP based phone networks, this 628 is bound to change. 630 Right now, there is no protocol support for controlled, secure, and 631 dynamic peering between enterprises. Once this is made possible, the 632 voice interconnection landscape is bound to change dramatically. 634 The future might look like a mixture between the email and the IP 635 world: The majority of end-users will still contract voice service 636 from large operators (either the same providers where they buy basic 637 connectivity, or independent, voice-only operators). Smaller 638 companies might run their own PBX (which buy upstream "minutes" from 639 operators) or just buy hosted voice services. Larger PBX 640 installations will be (from a technology point of view) 641 indistinguishable from smaller SSP. 643 5.2. Interconnection fabrics 645 How will these voice networks interconnect? An "interconnection 646 fabric" will be any physical or logical arrangement where two or more 647 voice operators interconnect. There will be a number of very 648 different such fabrics. No single one will be dominant. 650 5.2.1. Old-style TDM based interconnection 652 The SS7 technology will be here to stay for quite some time. 654 5.2.2. Private SIP interconnection 656 Whenever two SSPs use a dedicated IP link between their networks to 657 exchange calls, this is a trivial interconnection fabric. Such links 658 will be used for PBX to Upstream-SSP connections, as well as for 659 carrier to carrier peering, just like private peering links in the 660 Layer 3 world. 662 5.2.3. Commercial Peering Fabrics 664 Just as Internet Exchange Points have sprung up to simplify 665 interconnection on layer 3, similar dedicated SIP interconnection 666 facilities have appeared. These provide optimal conditions for 667 secure, QoS enabled L3 connections, coupled with support 668 infrastructure like directory services or SIP scrubbing. 670 5.2.4. Overlay networks 672 Instead of building a physical peering fabric, the public Internet 673 can be used to build a logical peering fabric. That can been done 674 with VPN technologies or just by implementing suitable access control 675 on SBEs. 677 5.2.5. RFC3263-style SIP 679 The set of all SSPs implementing SIP according to RFC 3263 also forms 680 a peering fabric. 682 5.3. An internet of Voice Networks 684 Just as the Layer 3 Internet is built by linking individual networks 685 together, the world-wide voice network will similarly emerges as the 686 meta-network that comprises all the member networks. 688 Such a meta-network (or a lower-case 'I' internet) needs as 689 precondition 691 o a common addressing scheme 692 o an inter-domain routing protocol 694 5.4. The Lookup Function (LUF) 696 The first step in all call processing is the mapping from telephone 697 number to the Destination-Group (see Section 4.4). 699 This mapping step is performed not only by commercial voice 700 operators, but also by PBX installations, if they have more than just 701 one upstream interconnection provider. As argued in Section 4.5, 702 this needs to be an on-demand lookup into an external database. That 703 database needs to accept queries from such a large number of 704 legitimate questioners that it is unfeasible to keep that data 705 private. 707 Regarding who can provision entries into that database, some more 708 restrictions seem plausible, e.g. all registered service providers 709 who directly provide service to the customer using that number. 711 The logical choice for the LUF is thus public Infrastructure ENUM. 713 In the case of URI-based dialing, ENUM cannot be used. We thus also 714 need some sort of LUF which maps domain-names to Destination-Group. 715 This assumes that all SIP URIs with the same domain-name will be 716 routed the same path. That is a reasonable design decision. 718 A trivial approach would be just to re-use the domain-name as the 719 Destination-Group. That works fine for carrier-owned domains, but 720 raises significant scaling issues if customer-owned domains are used 721 in AoRs. It is thus more sensible to define a simple DNS Resource 722 Record which indicates the Destination-Group for SIP URIs with this 723 domain-name. 725 As a corollary, the I-ENUM lookup could just as well return AoR SIP 726 URIs and only a second lookup into the DNS yields the Destination- 727 Group. 729 5.5. The Location Routing Function (LRF) 731 The second step in the call routing algorithm is the next-hop 732 selection based on the Destination-Group the LUF generated. 734 For each individual call, this is simply a lookup in a routing-table 735 which maps Destination-Group to one (or more) sets of "session 736 establishment data (SED)" records which describe the next SIP hop for 737 this call. This SED might contain such elements like IP address of 738 an SBE, TLS parameters to use, QoS parameters, transcoding 739 instructions, bandwidth limits and whatnot else. 741 This is straight-forward, and very much like the IP routing lookup 742 into the forwarding routing table. The tricky question is how this 743 routing table is constructed. There are multiple possibilities: 745 Static / Manual routing 747 A human operator can configure individual routing rules into the 748 system. 750 A dynamic routing protocol spoken between two connected networks 752 Here the human operator just configures basic rules concerning 753 which neighbors his systems should talk to and under which 754 constraints they should accept and prioritize routing information, 755 as well as what routes they should announce. This would be the 756 voice meta-network's equivalent to the BGP of the Layer 3 757 Internet. 759 Transit Routing is possible with such a protocol. 761 Route registries, e.g. run by Peering Fabrics 763 Support systems built into fabrics might act as a routing 764 clearinghouse which can reduce the n-squared complexity of a full 765 routing mesh on peering exchanges. The Layer 3 analogy would be 766 route-reflectors run by Internet exchange points. Such 767 clearinghouses work fine for pure peering relationships, but have 768 a hard time handling transit routing. 770 A dynamic routing protocol is vastly preferable to manual routing. 771 The data exchanged in such a protocol could to be structured roughly 772 in the following way: 774 Key 776 The key into the routing table is the Destination-Group (the 777 result of the LUF). 779 SED 781 This is the information the device handling the call needs to 782 generate SIP messages. 784 Route metadata 786 This information is needed to determine whether this route is 787 acceptable for the SSP receiving the route as well as for 788 priorizing alternative routes. It might contain: 790 * Network path (equivalent to the BGP AS-path) 791 * Re-distribution restrictions 792 * What media-types are supported 793 * Capacity-related data 794 * Regulatory data (what kind of networks are involved?) 795 * QoS offered by the route 796 * Trust (e.g. does the destination require some reputation 797 network score for the caller? SIP-Identity?) 798 * Commercial terms 800 Poor-man's multihoming of an enterprise PBX could be implemented by 801 allowing the LUF to return multiple Destination-Groups. 803 6. Design Pitfalls 805 Reading documents from various sources, a few common design mistakes 806 need to mentioned and cautioned against: 808 6.1. Reliance on fabric internals for multi-hop routing 810 The cardinal mistake here is to assume that a single peering / 811 interconnection fabric will be the sole means of interconnection 812 between SSPs. A good example is the design of the IPX (see 813 http://www.gsmworld.com/documents/ireg/ir3444.pdf) and the idea of 814 transparent SIP proxies within that network. From the scarce public 815 documentation available it seems like the L3 paths selected via BGP 816 routing should determine which (transparent) SIP proxies need to take 817 care of transit agreements. 819 This can work in theory as long as *all* possible destination 820 networks partake (i.e. the IP addresses associated with SBEs of the 821 target network) in the BGP routing cloud of the IPX. Even simple 822 non-IPX cross-links between two carriers mess up that scheme, let 823 alone the idea that enterprises will also want to do their own call 824 routing. 826 Generally speaking, a routing protocol within an interconnection 827 fabric cannot replace a routing protocol which finds the right fabric 828 over which to route the call. 830 6.2. Mistaking a protocol for softswitch/SBE control for LUF/LRF 832 The LUF and LRF steps need to happen somewhere in the SSPs network. 833 They don't necessarily need to be done directly on the device which 834 actually generates SIP messages. Neither need the inter-domain 835 routing data exchanges be done between the actual SBEs. There 836 certainly are good arguments for that, but this is not a given. (In 837 the Layer 3 Internet, this is the common practice: the actual routers 838 which do the IP packet routing speak BGP.) 840 For voice routing, it may well be a good choice to centralize the 841 routing protocol handling and call routing decision processing to 842 dedicated servers which are not in the SIP call path themselves. In 843 such a setup, the soft-switch / SBE needs to query this central 844 instance on what to do with each individual call. 846 That protocol is neither LUF, nor LRF. It is something completely 847 different. 849 What does this protocol need? The device needs to pack up all 850 information it has on that call (source URI, source "trunk", media 851 requested, destination TN / URI, softswitch ID) into a query, send 852 that to the central routing instance. The answer needs to contain 853 basically the SED (which set of attribute-value pairs) which tells 854 the softswitch exactly what do to. 856 Good role models are access servers for dial-in application and the 857 RADIUS protocol used there. ENUM is not suited for this. A number 858 of recent I-Ds proposing extensions to the basic ENUM algorithm (e.g. 859 source variability, encoding calling-party-ID in the query) and a 860 long list of URI parameters show that people have tried to force ENUM 861 to do something it wasn't design to do. One should use Radius, 862 Diameter, or even MGCP as inspiration on how this can be implemented. 864 6.3. Mixing LUF and LRF 866 There is a good reason for the LUF/LRF separation. The two functions 867 solve different problems and require different approaches (simple 868 lookup vs. routing protocol). 870 Just as with normal network layering, it is sometimes tempting to 871 violate the layering principles. For example, when the focus is not 872 so much on full-scale transit-capable VoIP routing as on very simple 873 SIP peering, then folding the LRF into the LUF can seem like a good 874 idea. 876 As with all layering-violations, the perceived simplification quickly 877 turns into a mess of workarounds once the scenario expands beyond the 878 trivial case. In this case, just consider the effect of number 879 portability on the routing table size. 881 6.4. Provisioning vs. routing 883 With the establishment of the DRINKS working group, data-exchange and 884 "provisioning" in the context of VoIP peering are now subject to IETF 885 work. The data-exchanges needed for LUF and LRF are very different: 887 To provision and implement the LUF, we need: 888 o a provisioning protocol which adds TN->Destination-Group mappings 889 to a registry 890 o a query protocol into that registry 891 o a database replication protocol to make local copies of LUF 892 registries possible 894 The data-exchange for the LRF is: 895 o Routing data updates between peering SSPs or a fabric's route 896 aggregator (a routing protocol) 898 These are two completely different types of data exchanges. The LUF 899 side is close to what needed to run the DNS, the second is a routing 900 protocol like BGP. Trying to find a unified solution to these two 901 problems is futile. 903 6.5. RFC 3263 is part of the problem 905 RFC 3263 hardcodes the email model of interconnection. With respect 906 to speermint, it is part of the problem, and not part of the 907 solution. 909 6.6. Disregarding enterprises 911 As mentioned above (Section 3.2), PBX interconnection used to be rare 912 and utilized completely different technology than carrier to carrier 913 interconnection. 915 This used to make sense in the TDM world, but in a VoIP landscape it 916 is essential that enterprises also get the tools to simplify peering. 917 As this is pure settlement-free peering, there is a huge potential 918 for ad-hoc, dynamic peering if the protocols coming out of speermint 919 and DRINKS support that in a secure manner. 921 The IETF should take great care that these two workinggroups do not 922 intentionally exclude the requirements from enterprise peering from 923 their work. 925 7. What building-blocks are missing? 927 A mentioned before, the LUF lookup could be implemented via 928 Infrastructure ENUM, so no new protocol work is needed in that case, 929 only a new enumservice-type needs to be defined. More work is needed 930 for other parts of the framework: 932 7.1. LUF / I-ENUM provisioning 934 EPP combined with the ENUM extension is a possible solution. Some 935 enhancements (e.g. block provisioning) and better support for the 936 typical number portability operations might be needed, though. There 937 has been good input into the DRINKS WG on that topic. 939 7.2. LRF Routing announcements 941 There currently is no IETF protocol suitable for this data-exchange. 943 7.3. A call-control protocol 945 As mentioned above (Section 6.2), Radius or similar protocol might be 946 suitable. 948 8. Security Considerations 950 Not applicable at this stage of the discussion. 952 9. IANA Considerations 954 Not applicable. 956 10. Acknowledgements 958 The ideas expressed in this draft evolved during discussions with a 959 large number of people. Version -01 includes significant input from 960 Hannes Tschofenig. 962 11. References 964 11.1. Normative References 966 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 967 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 968 Application (ENUM)", RFC 3761, April 2004. 970 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 971 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 972 Session Initiation Protocol", RFC 3261, June 2002. 974 [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 975 (SIP): Locating SIP Servers", RFC 3263, June 2002. 977 11.2. Informative References 979 [4] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing 980 over IP (TRIP)", RFC 3219, January 2002. 982 [5] Peterson, J. and C. Jennings, "Enhancements for Authenticated 983 Identity Management in the Session Initiation Protocol (SIP)", 984 RFC 4474, August 2006. 986 [6] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol 987 (SIP) and Spam", RFC 5039, January 2008. 989 Author's Address 991 Otmar Lendl 992 enum.at GmbH 993 Karlsplatz 1/9 994 Wien A-1010 995 Austria 997 Phone: +43 1 5056416 33 998 Email: otmar.lendl@enum.at 999 URI: http://www.enum.at/ 1001 Full Copyright Statement 1003 Copyright (C) The IETF Trust (2008). 1005 This document is subject to the rights, licenses and restrictions 1006 contained in BCP 78, and except as set forth therein, the authors 1007 retain all their rights. 1009 This document and the information contained herein are provided on an 1010 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1011 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1012 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1013 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1014 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1015 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1017 Intellectual Property 1019 The IETF takes no position regarding the validity or scope of any 1020 Intellectual Property Rights or other rights that might be claimed to 1021 pertain to the implementation or use of the technology described in 1022 this document or the extent to which any license under such rights 1023 might or might not be available; nor does it represent that it has 1024 made any independent effort to identify any such rights. Information 1025 on the procedures with respect to rights in RFC documents can be 1026 found in BCP 78 and BCP 79. 1028 Copies of IPR disclosures made to the IETF Secretariat and any 1029 assurances of licenses to be made available, or the result of an 1030 attempt made to obtain a general license or permission for the use of 1031 such proprietary rights by implementers or users of this 1032 specification can be obtained from the IETF on-line IPR repository at 1033 http://www.ietf.org/ipr. 1035 The IETF invites any interested party to bring to its attention any 1036 copyrights, patents or patent applications, or other proprietary 1037 rights that may cover technology that may be required to implement 1038 this standard. Please address the information to the IETF at 1039 ietf-ipr@ietf.org. 1041 Acknowledgment 1043 Funding for the RFC Editor function is provided by the IETF 1044 Administrative Support Activity (IASA).