idnits 2.17.1 draft-ietf-speermint-reqs-and-terminology-01.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 488. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 17, 2006) is 6614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.E164.1991' -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-01) exists of draft-lind-infrastructure-enum-reqs-00 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Meyer 2 Internet-Draft February 17, 2006 3 Expires: August 21, 2006 5 SPEERMINT Requirements and Terminology 6 draft-ietf-speermint-reqs-and-terminology-01.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 21, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 This document outlines the solutions space requirements and defines 40 the terminology that is to be used by the Session PEERing for 41 Multimedia INTerconnect Working Group (SPEERMINT). It has as its 42 primary objective to focus the working group during its discussions, 43 and when writing requirements, gap analysis and other solutions 44 oriented documents. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 52 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 56 3.6. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.6.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 5 58 3.6.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 59 3.7. Session Peering . . . . . . . . . . . . . . . . . . . . . 6 60 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Unified solution for all peering policies . . . . . . . . 7 67 5.2. Domain Based . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.3. No blocked calls . . . . . . . . . . . . . . . . . . . . . 8 69 5.4. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.5. Independence of lower layers . . . . . . . . . . . . . . . 8 71 5.6. Administrative and technical policies . . . . . . . . . . 8 72 5.7. Minimal additional cost on call initiation . . . . . . . . 9 73 5.8. Look beyond SIP . . . . . . . . . . . . . . . . . . . . . 9 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 Intellectual Property and Copyright Statements . . . . . . . . . . 10 83 1. Introduction 85 The term "VoIP Peering" has historically been used to describe a wide 86 variety of aspects pertaining to the interconnection of service 87 provider networks and to the delivery of SIP call termination over 88 those interconnections. The discussion of these interconnections has 89 at times been confused by the fact that the term "peering" is used in 90 various contexts to relate to interconnection at different levels in 91 a protocol stack. Session Peering for Multimedia Interconnect 92 focuses on how to identify and route real-time sessions (such as VoIP 93 calls) at the application layer, and it does not (necessarily) 94 involve the exchange of packet routing data or media sessions. In 95 particular, "layer 5 network" is used here to refer to the 96 interconnection between SIP servers, as opposed to interconnection at 97 the IP layer ("layer 3"). Finally, the terms "peering" and 98 "interconnect" are used interchangeably throughout this document. 100 This document introduces standard terminology for use in 101 characterizing real-time session interconnection. Note however, that 102 while this document is primarily targeted at the VoIP interconnect 103 case, the terminology described here is applicable to those cases in 104 which service providers interconnect using SIP signaling for real- 105 time or quasi-real-time communications. 107 The remainder of this document is organized as follows: Section 2 108 provides the general context for the SPEERMINT Working Group. 109 Section 3 provides the general definitions for real-time SIP based 110 communication, with initial focus on the VoIP interconnect case, and 111 Section 4 briefly touches on terms from the ENUM Working Group. 112 Finally, Section 5 provides the requirements for SPEERMINT working 113 group solutions. 115 2. Context 117 Figure 1 depicts the general VoIP interconnect context. In this 118 case, the caller uses an E.164 number [ITU.E164.1991] as the "name" 119 of the called user. Note that this E.164 number is not an address, 120 since at this point we do not have information about where the named 121 endpoint is located. In the case shown here, an E.164 number is used 122 as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in 123 turn resolved into a SIP URI. Call routing is based on this SIP URI. 124 The call routing step does not depend on the presence of an E.164 125 number; the SIP URI can be advertised in various other ways, such as 126 on a web page. Finally, note that the subsequent lookup steps, 127 namely, lookup of SRV, A, and AAAA records (as well as any routing 128 steps below that) are outside the scope of SPEERMINT. 130 E.164 number <--- Peer Discovery 131 | 132 | <--- ENUM lookup of NAPTR in DNS 133 | 134 | 135 | ENUM Working Group Scope 136 =====+======================================= 137 | SPEERMINT Working Group Scope 138 | 139 | 140 SIP URI <--- Call Routing Data (CRD) 141 | 142 | <--- Service Location (Lookup of SRV in DNS) 143 | 144 | 145 Hostname <--- Addressing and session establishment 146 | 147 | <---- Lookup of A and AAAA in DNS 148 | 149 Ip address 150 | 151 | <---- Routing protocols, ARP etc 152 | 153 Mac-address 155 Figure 1: Session Interconnect Context 157 The ENUM Working Group is primarily concerned with the acquisition of 158 Call Routing Data, or CRD (i.e., above the double line in Figure 1), 159 while the SPEERMINT Working Group is focused on the use of such CRD. 160 Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS 161 entry), or via any other mechanism available to the user. 163 3. General Definitions 165 3.1. Call Routing Data 167 Call Routing Data, or CRD, is a SIP URI used to route a call (real- 168 time, voice or other type) to the called domain's ingress point. A 169 domain's ingress point can be thought of as the location pointed to 170 by the SRV record that resulted from the resolution of the CRD (i.e., 171 a SIP URI). 173 3.2. Call Routing 175 Call routing is the set of processes, rules, and CRD used to route a 176 call to its proper (SIP) destination. More generally, call routing 177 can be thought of as the set of processes, rules and CRD which are 178 used to route a real-time session to its termination (ingress) point. 180 3.3. PSTN 182 The term "PSTN" refers to the Public Switched Telephone Network. In 183 particular, the PSTN refers to the collection of interconnected 184 circuit-switched voice-oriented public telephone networks, both 185 commercial and government-owned. In general, PSTN terminals are 186 addressed using E.164 numbers, noting that various dial-plans (such 187 as emergency services dial-plans) may not directly use E.164 numbers. 189 3.4. Network 191 For purposes of this document and the SPEERMINT and ENUM Working 192 Groups, a network is defined to be the set of SIP servers and end- 193 users (customers) that are controlled by a single administrative 194 domain. The network may also contain end-users who are located on 195 the PSTN. 197 3.5. VoIP Service Provider 199 A VoIP service provider is an entity that provides transport of SIP 200 signaling (and possibly media streams) to its customers. Such a 201 service provider may additionally be interconnected with other 202 service providers; that is, it may "peer" with other service 203 providers. A VoIP service provider may also interconnect with the 204 PSTN. 206 Note that as soon as a ingress point is advertised via a SRV record, 207 anyone can find that ingress point and hence can send calls there. 208 This is very similar to sending mail to a SMTP server based on the 209 existence of a MX record. 211 3.6. Peering 213 While the precise definition of the term "peering" is the subject of 214 some debate, peering in general refers to the negotiation of 215 reciprocal interconnection arrangements, settlement-free or 216 otherwise, between operationally independent service providers. 218 This document distinguishes two types of peering, Layer 3 Peering and 219 Layer 5 peering, which are described below. 221 3.6.1. Layer 3 Peering 223 Layer 3 peering refers to interconnection of two service providers 224 for the purposes of exchanging IP packets which destined for one (or 225 both) of the peer's networks. Layer 3 peering is generally agnostic 226 to the IP payload, and is frequently achieved using a routing 227 protocol such as BGP [RFC1771] to exchange the required routing 228 information. 230 An alternate, perhaps more operational definition of layer 3 peering 231 is that two peers exchange only customer routes, and hence any 232 traffic between peers terminates on one of the peer's network. 234 3.6.2. Layer 5 Peering 236 Layer 5 peering refers to interconnection of two service providers 237 for the purposes of SIP signaling. Note that in the layer 5 peering 238 case, there is no intervening network. That is, for purposes of this 239 discussion, there is no such thing as a "Layer 5 Transit Network". 241 3.7. Session Peering 243 Session peering is defined to be a layer 5 peering between two VoIP 244 providers for purposes of routing real-time (or quasi-real time) call 245 signaling between their respective customers. Media streams 246 associated with this signaling (if any) are not constrained to follow 247 the same set of paths. 249 4. ENUM 251 ENUM [RFC3761] defines how the Domain Name System (DNS) can be used 252 for identifying available services connected to one E.164 number. 254 4.1. Carrier of Record 256 For purposes of this document, "Carrier of Record", or COR, refers to 257 the entity that provides PSTN service for an E.164 number 258 [I-D.lind-infrastructure-enum-reqs]. The exact definition of who and 259 what is a COR is ultimately the responsibility of the relevant 260 National Regulatory Authority. 262 4.2. Public ENUM 264 Public ENUM is generally defined as the set administrative policies 265 and procedures surrounding the use of the e164.arpa domain for 266 Telephone Number to URI resolution [RFC3761]. Policies and 267 procedures for the registration of telephone numbers within all 268 branches of the e164.arpa tree are Nation State issues by agreement 269 with the IAB and ITU. National Regulatory Authorities have generally 270 defined Public ENUM Registrants as the E.164 number holder as opposed 271 to the COR that issued the phone number. 273 4.3. Private ENUM 275 Private ENUM is generally regarded as one or more technologies 276 (including DNS and SIP Redirect) that service providers or 277 enterprises may use to exchange phone number to URI mappings in a 278 private secure manner. Private ENUM may be used in any mutually 279 agreed upon domain. Records in Private ENUM may be globally visible 280 but in most cases are not visible to the global Internet and are 281 protected using a variety of security technologies such as split-DNS, 282 VPN's or various forms or authentication and authorization. 283 Technical comments on issues surrounding split-DNS can be found in 284 [RFC2826]. 286 4.4. Carrier ENUM 288 Carrier ENUM is generally regarded as the use of a separate branch 289 the e164.arpa tree, such as 4.4.c.e164.arpa to permit service 290 providers to exchange phone number to URI data in order to find 291 points of interconnection. The current theory of Carrier ENUM is 292 that only the COR for a particular E.164 number is permitted to 293 provision data for that E.164 within that portion of the e164.arpa 294 tree. 296 In carrier ENUM case, only the COR may enter data in the 297 corresponding domain. The COR may also enter CRD (i.e., a SIP URI) 298 to allow other VoIP Service Providers to route calls to its network. 300 Finally, note that ENUM is not constrained to carry only data (CDR) 301 as defined by SPEERMINT. In particular, an an important class of 302 CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs 303 are most frequently used to interconnect with the PSTN directly, and 304 are out of scope for SPEERMINT. On the other hand, PSTN endpoints 305 served by a COR and reachable via CDR and networks as defined in 306 Section 3.1 and Section 3.4 are in scope for SPEERMINT. 308 5. Requirements 310 A system for real-time session interconnection must satisfy the 311 following requirements: 313 5.1. Unified solution for all peering policies 315 Policies developed in the context of the SPEERMINT working group must 316 be extensible and flexible enough to cover existing and future 317 peering policies. These start by a closed system which accepts only 318 incoming calls from selected peers (i.e. a set of bilateral peerings) 319 and include the model of membership in a number of peering fabrics or 320 carrier clubs. The case of an open SIP proxy should be covered as a 321 special case as well. 323 5.2. Domain Based 325 Although the initial call routing may be based on E.164 numbers, a 326 generic peering methodology should not rely on such numbers. Rather, 327 call routing should rely on URIs. We assume that all SIP URIs with 328 the same domain-part share the same set of peering policies, thus the 329 domain of the SIP URI may be used as the primary key to any 330 information regarding the reachability of that SIP URI. 332 5.3. No blocked calls 334 An originating service provide must be able to determine whether a 335 SIP URI is open for direct interconnection without actually sending a 336 SIP INVITE. This is important as unsuccessful call attempts are 337 highly undesirable since they can introduce high delays due to 338 timeouts and can act as an unintended denial of service attack. 339 (e.g., by repeated TLS handshakes). 341 5.4. Scaling 343 The maintenance of the system needs to scale beyond simple lists of 344 peering partners. In particular, it must incorporate aggregation 345 mechanisms which avoid O(n^2) scaling (where n is the number of 346 participating service providers). Per-service provider opt-in 347 without consultation of a centralized 'peering registry', but rather 348 by publishing local configuration choices only is highly desirable. 349 The distributed management of the DNS is a good example for the 350 scalability of this approach. 352 5.5. Independence of lower layers 354 The system needs to be independent of details on what technologies 355 are used route the call and which are used to ensure that only 356 approved peering partner actually connect to the destination SIP 357 proxy. It should not matter whether restrictions are implemented by 358 private L3 connectivity ("walled gardens"), firewalls, TLS policies 359 or SIP proxy configuration. 361 5.6. Administrative and technical policies 363 The reasons for declining vs. accepting incoming calls from a 364 prospective peering partner can be both administrative (contractual, 365 legal, commercial, or business decisions) and technical (certain QoS 366 parameters, TLS keys, domain keys, ...). Methodologies developed by 367 the SPEERMINT working group should accommodate all policies. 369 5.7. Minimal additional cost on call initiation 371 Since each call setup implies execution of any proposed algorithm it 372 should incur minimal overhead and delay, and employ caching wherever 373 possible to avoid extra protocol round trips. 375 5.8. Look beyond SIP 377 The problem of selective peering is not limited to SIP-based 378 communication. Other protocols may benefit from a generic framework 379 as well, such as SMTP mail. Any solutions proposed by the SPEERMINT 380 working group must be generic enough to encompass other protocols as 381 well. 383 6. Acknowledgments 385 Many of the definitions were gleaned from detailed discussions on the 386 SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, 387 Jean-Francois Mule, Richard Shocky, Henry Sinnreich, and Richard 388 Stastny all made valuable contributions to early revisions of this 389 document. Patrik Faltstrom also made many insightful comments to 390 early versions of this draft, and contributed the basis of Figure 1. 391 Finally, Otmar Lendl contributed much of the text found in the 392 Requirements section. 394 7. Security Considerations 396 This document itself introduces no new security considerations. 397 However, it is important to note that Session interconnect, as 398 described in this document, has a wide variety of security issues 399 that should be considered in documents addressing both protocol and 400 use case analyzes. 402 8. IANA Considerations 404 This document creates no new requirements on IANA namespaces 405 [RFC2434]. 407 9. References 409 9.1. Normative References 411 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 412 Part Four: The Uniform Resource Identifiers (URI)", 413 RFC 3404, October 2002. 415 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 416 Resource Identifiers (URI) Dynamic Delegation Discovery 417 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 419 [ITU.E164.1991] 420 International Telecommunications Union, "The International 421 Public Telecommunication Numbering Plan", ITU- 422 T Recommendation E.164, 1991. 424 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 425 RFC 3966, December 2004. 427 9.2. Informative References 429 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 430 (BGP-4)", RFC 1771, March 1995. 432 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 433 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 434 October 1998. 436 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 437 Unique DNS Root", RFC 2826, May 2000. 439 [I-D.lind-infrastructure-enum-reqs] 440 Lind, S., "Infrastructure ENUM Requirements", 441 draft-lind-infrastructure-enum-reqs-00 (work in progress), 442 July 2005. 444 Author's Address 446 David Meyer 448 Email: dmm@1-4-5.net 450 Full Copyright Statement 452 Copyright (C) The Internet Society (2006). 454 This document is subject to the rights, licenses and restrictions 455 contained in BCP 78, and except as set forth therein, the authors 456 retain all their rights. 458 This document and the information contained herein are provided on an 459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 461 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 462 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 463 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Intellectual Property 468 The IETF takes no position regarding the validity or scope of any 469 Intellectual Property Rights or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; nor does it represent that it has 473 made any independent effort to identify any such rights. Information 474 on the procedures with respect to rights in RFC documents can be 475 found in BCP 78 and BCP 79. 477 Copies of IPR disclosures made to the IETF Secretariat and any 478 assurances of licenses to be made available, or the result of an 479 attempt made to obtain a general license or permission for the use of 480 such proprietary rights by implementers or users of this 481 specification can be obtained from the IETF on-line IPR repository at 482 http://www.ietf.org/ipr. 484 The IETF invites any interested party to bring to its attention any 485 copyrights, patents or patent applications, or other proprietary 486 rights that may cover technology that may be required to implement 487 this standard. Please address the information to the IETF at 488 ietf-ipr@ietf.org. 490 Acknowledgment 492 Funding for the RFC Editor function is currently provided by the 493 Internet Society.