idnits 2.17.1 draft-meyer-voipeer-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 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 393. ** 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 (October 21, 2005) is 6755 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) == Unused Reference: 'I-D.lind-infrastructure-enum-reqs' is defined on line 360, but no explicit reference was found in the text ** 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 (~~), 4 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 October 21, 2005 3 Expires: April 24, 2006 5 Terminology for Describing VoIP Peering and Interconnect 6 draft-meyer-voipeer-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 April 24, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 37 Abstract 39 This document defines the terminology that is to be used by the Voice 40 Over IP Peering and Interconnect Working Group (voipeer), and has as 41 its primary objective to focus the VOIPEER Working Group during its 42 discussions, and when writing requirements, gap analysis and other 43 solutions oriented documents. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 51 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 55 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 58 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 59 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . . . . 11 75 1. Introduction 77 The term "VoIP Peering" has historically been used to describe a wide 78 variety of aspects pertaining to the interconnection of service 79 provider networks and to the delivery of SIP call termination over 80 those interconnections. The discussion of these interconnections has 81 at times been confused by the fact that the term "peering" is used in 82 various contexts to relate to interconnection at different levels in 83 a protocol stack. VoIP peering focuses on how to identify and route 84 calls at the application layer, and it does not (necessarily) involve 85 the exchange of packet routing data or media sessions. In 86 particular, "layer 5 network" is used here to refer to the 87 interconnection between SIP servers, as opposed to interconnection at 88 the IP layer ("layer 3"). Finally, the terms "peering" and 89 "interconnect" are used interchangeably throughout this document. 91 This document introduces standard terminology for use in 92 characterizing VoIP interconnection. Note however, that while this 93 document is primarily targeted at the VoIP interconnect case, the 94 terminology described here is applicable to those cases in which 95 service providers interconnect using SIP signaling for real-time or 96 quasi-real-time communications. 98 The remainder of this document is organized as follows: Section 2 99 provides the general context for the VOIPEER Working Group, and 100 Section 3 provides the general definitions for real-time SIP based 101 communication, with focus on the VoIP interconnect case. Section 4 102 briefly touches on terms from the ENUM Working Group. Finally, 103 Section 5 provides comments on usage. 105 2. Context 107 Figure 1 depicts the general VoIP interconnect context. In this 108 case, the caller uses an E.164 number [ITU.E164.1991] as the "name" 109 of the called user. Note that this E.164 number is not an address, 110 since at this point we do not have information about where the named 111 endpoint is located. In the case shown here, an E.164 number is used 112 as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in 113 turn resolved into a SIP URI. Call routing is based on this SIP URI. 114 The call routing step does not depend on the presence of an E.164 115 number; the SIP URI can be advertised in various other ways, such as 116 on a web page. Finally, note that the subsequent lookup steps, 117 namely, lookup of SRV, A, and AAAA records (as well as any routing 118 steps below that) are outside the scope of VOIPEER. 120 E.164 number <--- Peer Discovery 121 | 122 | <--- ENUM lookup of NAPTR in DNS 123 | 124 | 125 | ENUM Working Group Scope 126 =====+======================================= 127 | VOIPEER Working Group Scope 128 | 129 | 130 SIP URI <--- Call Routing Data (CRD) 131 | 132 | <--- Service Location (Lookup of SRV in DNS) 133 | 134 | 135 Hostname <--- VoIP addressing and session establishment 136 | 137 | <---- Lookup of A and AAAA in DNS 138 | 139 Ip address 140 | 141 | <---- Routing protocols, ARP etc 142 | 143 Mac-address 145 Figure 1: VoIP Interconnect Context 147 The ENUM Working Group is primarily concerned with the acquisition of 148 Call Routing Data, or CRD (i.e., above the double line in Figure 1), 149 while the VOIPEER Working Group is focused on the use of such CRD. 150 Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS 151 entry), or via any other mechanism available to the user. 153 3. General Definitions 155 3.1. Call Routing Data 157 Call Routing Data, or CRD, is a SIP URI used to route a call (real- 158 time, voice or other type) to the called domain's ingress point. A 159 domain's ingress point can be thought of as the location pointed to 160 by the SRV record that resulted from the resolution of the CRD (i.e., 161 a SIP URI). 163 3.2. Call Routing 165 Call routing is the set of processes, rules, and CRD used to route a 166 VoIP call to its proper (SIP) destination. More generally, call 167 routing can be thought of as the set of processes, rules and CRD 168 which are used to route a real-time session to its termination 169 (ingress) point. 171 3.3. PSTN 173 The term "PSTN" refers to the Public Switched Telephone Network. In 174 particular, the PSTN refers to the collection of interconnected 175 circuit-switched voice-oriented public telephone networks, both 176 commercial and government-owned. In general, PSTN terminals are 177 addressed using E.164 numbers, noting that various dial-plans (such 178 as emergency services dial-plans) may not directly use E.164 numbers. 180 3.4. Network 182 For purposes of this document and the VOIPEER and ENUM Working 183 Groups, a network is defined to be the set of SIP servers and end- 184 users (customers) that are controlled by a single administrative 185 domain. The network may also contain end-users who are located on 186 the PSTN. 188 3.5. VoIP Service Provider 190 A VoIP service provider is an entity that provides transport of SIP 191 signaling (and possibly media streams) to its customers. Such a 192 service provider may additionally be interconnected with other 193 service providers; that is, it may "peer" with other service 194 providers. A VoIP service provider may also interconnect with the 195 PSTN. 197 Note that as soon as a ingress point is advertised via a SRV record, 198 anyone can find that ingress point and hence can send calls there. 199 This is very similar to sending mail to a SMTP server based on the 200 existence of a MX record. 202 3.6. Carrier 204 A carrier is defined to be a service provider who is authorized to 205 offer telephony services to the public. Note that the provision of 206 such services is usually coupled with the authority to issue E.164 207 numbers [ITU.E164.1991] under the authority of a National Regulatory 208 Authority (NRA). 210 3.7. Peering 212 While the precise definition of the term "peering" is the subject of 213 some debate, peering in general refers to the negotiation of 214 reciprocal interconnection arrangements, settlement-free or 215 otherwise, between operationally independent service providers. 217 This document distinguishes two types of peering, Layer 3 Peering and 218 Layer 5 peering, which are described below. 220 3.7.1. Layer 3 Peering 222 Layer 3 peering refers to interconnection of two service providers 223 for the purposes of exchanging IP packets which destined for one (or 224 both) of the peer's networks. Layer 3 peering is generally agnostic 225 to the IP payload, and is frequently achieved using a routing 226 protocol such as BGP [RFC1771] to exchange the required routing 227 information. 229 An alternate, perhaps more operational definition of layer 3 peering 230 is that two peers exchange only customer routes, and hence any 231 traffic between peers terminates on one of the peer's network. 233 3.7.2. Layer 5 Peering 235 Layer 5 peering refers to interconnection of two service providers 236 for the purposes of SIP signaling. Note that in the layer 5 peering 237 case, there is no intervening network. That is, for purposes of this 238 discussion, there is no such thing as a "Layer 5 Transit Network". 240 3.8. VoIP Peering 242 VoIP peering is defined to be a layer 5 peering between two VoIP 243 providers for purposes of routing real-time (or quasi-real time) call 244 signaling between their respective customers. Media streams 245 associated with this signaling (if any) are not constrained to follow 246 the same set of paths. 248 4. ENUM 250 ENUM [RFC3761] defines how the Domain Name System (DNS) can be used 251 for identifying available services connected to one E.164 number. 253 4.1. Carrier of Record 255 For purposes of this document, "Carrier of Record", or COR, refers to 256 the entity that provides PSTN service for an E.164 number [I-D.lind- 257 infrastructure-enum-reqs]. The exact definition of who and what is a 258 COR is ultimately the responsibility of the relevant NRA. 260 4.2. Public ENUM 262 Public ENUM is generally defined as the set administrative policies 263 and procedures surrounding the use of the e164.arpa domain for 264 Telephone Number to URI resolution [RFC3761]. Policies and 265 procedures for the registration of telephone numbers within all 266 branches of the e164.arpa tree are Nation State issues by agreement 267 with the IAB and ITU. National Regulatory Authorities have generally 268 defined Public ENUM Registrants as the E.164 number holder as opposed 269 to the COR that issued the phone number. 271 4.3. Private ENUM 273 Private ENUM is generally regarded as one or more technologies 274 (including DNS and SIP Redirect) that service providers or 275 enterprises may use to exchange phone number to URI mappings in a 276 private secure manner. Private ENUM may be used in any mutually 277 agreed upon domain. Records in Private ENUM may be globally visible 278 but in most cases are not visible to the global Internet and are 279 protected using a variety of security technologies such as split-DNS, 280 VPN's or various forms or authentication and authorization. 281 Technical comments on issues surrounding split-DNS can be found in 282 [RFC2826]. 284 4.4. Carrier ENUM 286 Carrier ENUM is generally regarded as the use of a separate branch 287 the e164.arpa tree, such as 4.4.c.e164.arpa to permit service 288 providers to exchange phone number to URI data in order to find 289 points of interconnection. The current theory of Carrier ENUM is 290 that only the COR for a particular E.164 number is permitted to 291 provision data for that E.164 within that portion of the e164.arpa 292 tree. 294 In carrier ENUM case, only the COR may enter data in the 295 corresponding domain. The COR may also enter CRD (i.e., a SIP URI) 296 to allow other VoIP Service Providers to route calls to its network. 298 Finally, note that ENUM is not constrained to carry only data (CDR) 299 as defined by VOIPEER. In particular, an an important class of CRD, 300 the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are 301 most frequently used to interconnect with the PSTN directly, and are 302 out of scope for VOIPEER. On the other hand, PSTN endpoints served 303 by a COR and reachable via CDR and networks as defined in Section 3.1 304 and Section 3.4 are in scope for VOIPEER. 306 5. Conclusions 307 6. Acknowledgments 309 Many of the definitions were gleaned from detailed discussions on the 310 VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, 311 Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable 312 contributions to early revisions of this document. Patrik Faltstrom 313 also made many insightful comments to early versions of this draft, 314 and contributed the basis of Figure 1. 316 7. Security Considerations 318 This document itself introduces no new security considerations. 319 However, it is important to note that VoIP interconnect has a wide 320 variety of security issues that should be considered in documents 321 addressing both protocol and use case analyzes. 323 8. IANA Considerations 325 This document creates no new requirements on IANA namespaces 326 [RFC2434]. 328 9. References 330 9.1. Normative References 332 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 333 Part Four: The Uniform Resource Identifiers (URI)", 334 RFC 3404, October 2002. 336 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 337 Resource Identifiers (URI) Dynamic Delegation Discovery 338 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 340 [ITU.E164.1991] 341 International Telecommunications Union, "The International 342 Public Telecommunication Numbering Plan", ITU- 343 T Recommendation E.164, 1991. 345 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 346 RFC 3966, December 2004. 348 9.2. Informative References 350 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 351 (BGP-4)", RFC 1771, March 1995. 353 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 354 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 355 October 1998. 357 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 358 Unique DNS Root", RFC 2826, May 2000. 360 [I-D.lind-infrastructure-enum-reqs] 361 Lind, S., "Infrastructure ENUM Requirements", 362 draft-lind-infrastructure-enum-reqs-00 (work in progress), 363 July 2005. 365 Author's Address 367 David Meyer 369 Email: dmm@1-4-5.net 371 Intellectual Property Statement 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights that may cover technology that may be required to implement 392 this standard. Please address the information to the IETF at 393 ietf-ipr@ietf.org. 395 Disclaimer of Validity 397 This document and the information contained herein are provided on an 398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 400 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 401 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 402 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Copyright Statement 407 Copyright (C) The Internet Society (2005). This document is subject 408 to the rights, licenses and restrictions contained in BCP 78, and 409 except as set forth therein, the authors retain all their rights. 411 Acknowledgment 413 Funding for the RFC Editor function is currently provided by the 414 Internet Society.