idnits 2.17.1 draft-ietf-speermint-terminology-17.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 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. 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 (November 7, 2008) is 5642 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 444, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 448, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 461, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 464, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 467, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3761 (ref. '4') (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '9') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '10') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 761 (ref. '12') (Obsoleted by RFC 793, RFC 7805) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPEERMINT Working Group D. Malas, Ed. 2 Internet-Draft CableLabs 3 Intended status: Informational D. Meyer, Ed. 4 Expires: May 2009 November 7, 2008 6 SPEERMINT Terminology 7 draft-ietf-speermint-terminology-17.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 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 7, 2009. 35 Abstract 37 This document defines the terminology that is to be used in 38 describing Session PEERing for Multimedia INTerconnect (SPEERMINT). 40 Table of Contents 42 1. Introduction...................................................2 43 2. SPEERMINT Context..............................................3 44 3. General Definitions............................................3 45 3.1. Signaling Path Border Element.............................3 46 3.2. Data Path Border Element..................................4 47 3.3. Session Establishment Data................................4 48 3.4. Call Routing..............................................5 49 3.5. PSTN......................................................5 50 3.6. IP Path...................................................5 51 3.7. Peer Network..............................................5 52 3.8. Service Provider..........................................5 53 3.9. SIP Service Provider......................................5 54 4. Peering........................................................6 55 4.1. Layer 3 Peering...........................................6 56 4.2. Layer 5 Peering...........................................6 57 4.2.1. Direct Peering.......................................6 58 4.2.2. Indirect Peering.....................................6 59 4.2.3. On-demand Peering....................................7 60 4.2.4. Static Peering.......................................7 61 4.3. Functions.................................................7 62 4.3.1. Signaling Function...................................7 63 4.3.2. Media Function.......................................7 64 4.3.3. Look-Up Function.....................................7 65 4.3.4. Location Routing Function............................8 66 5. Federations....................................................8 67 6. Acknowledgments................................................9 68 7. Security Considerations........................................9 69 8. IANA Considerations............................................9 70 9. Informative References.........................................9 71 Author's Addresses...............................................11 72 Intellectual Property Statement..................................11 73 Disclaimer of Validity...........................................11 74 Copyright Statement..............................................12 75 Acknowledgment...................................................12 77 1. Introduction 79 The term "Voice over IP Peering" (VoIP Peering) has historically been 80 used to describe a wide variety of practices pertaining to the 81 interconnection of service provider networks and to the delivery of 82 Session Initiation Protocol (SIP [2]) call termination over those 83 interconnections. 85 The discussion of these interconnections has at times been confused 86 by the fact that the term "peering" is used in various contexts to 87 describe interconnection at different levels in a protocol stack. 88 Session Peering for Multimedia Interconnect focuses on how to 89 identify and route real-time sessions (such as VoIP calls) at the 90 session layer, and it does not (necessarily) cover the exchange of 91 packet routing data or media sessions. In particular, "layer 5 92 network" is used here to refer to the interconnection between SIP 93 servers, as opposed to interconnection at the IP layer ("layer 3"). 94 The term "peering" will be used throughout the remainder of the 95 document for the purpose of indicating a layer 5 interconnection. 97 This document introduces standard terminology for use in 98 characterizing real-time session peering. Note however, that while 99 this document is primarily targeted at the VoIP peering case, the 100 terminology described here is applicable to those cases in which 101 service providers peer using SIP signaling (defined as SIP Service 102 Providers, See Section 3.9) for non-voice or quasi-real-time 103 communications like instant messaging. 105 The remainder of this document is organized as follows: Section 2 106 provides the general context for the Session PEERing for Multimedia 107 INTerconnect Working Group (SPEERMINT). Section 3 provides the 108 general definitions for real-time SIP based communication, with 109 initial focus on the VoIP peering case, and Section 4 defines the 110 terminology describing the various forms of peering. Finally, Section 111 5 introduces the concept of federations. 113 2. SPEERMINT Context 115 SPEERMINT provides a peering framework which leverages the building 116 blocks of existing IETF defined protocols such as SIP [2] and ENUM 117 [4]. While the SPEERMINT working group describes the use of these 118 protocols in peering, it does not redefine how these protocols use 119 input or output variables necessary for creating Session 120 Establishment Data (SED) or the methods in which this data will be 121 used during the peering process. See Section 3.3 for additional 122 detail on SED and its principal variables such as telephone numbers 123 of E.164 numbers [5] and Uniform Resource Identifiers (URI) [3]. For 124 example, while the SPEERMINT working group is not limited to the use 125 of telephone numbers, an E.164 number may be used as a key in an 126 E.164 to URI mapping using ENUM. This mapping involves looking up 127 Naming Authority Pointer (NAPTR) records in the DNS and results in a 128 SIP URI. The process for deriving this information has already been 129 defined in [4], but is used as a building block for SPEERMINT SED, on 130 which the subsequent call routing is based. Note that the call 131 routing step does not depend on the presence of an E.164 number. 132 Indeed, the URI resulting from an ENUM query may no longer even 133 contain numbers of any type. In particular, the SIP URI can be 134 advertised in various other ways, such as on a web page. 136 Finally, note that the term "call" is being used here in the most 137 general sense, i.e., call routing and session routing are used 138 interchangeably. 140 3. General Definitions 142 3.1. Signaling Path Border Element 144 A signaling path border element (SBE) is located on the 145 administrative border of a domain through which inter-domain session 146 layer messages will flow. It typically provides signaling functions 147 such as protocol inter-working (for example, H.323 to SIP), identity 148 and topology hiding, and Session Admission Control for a domain. 150 3.2. Data Path Border Element 152 A data path border element (DBE) is located on the administrative 153 border of a domain through which flows the media associated with an 154 inter-domain session. It typically provides media-related functions 155 such as deep packet inspection and modification, media relay, and 156 firewall traversal support. The DBE may be controlled by the SBE. 158 3.3. Session Establishment Data 160 Session Establishment Data, or SED, is the data used to route a call 161 to the next hop associated with the called domain's ingress point. A 162 domain's ingress point might for example be the location derived from 163 various types of DNS records (NAPTR, SRV, and A record) [1] that 164 resulted from the resolution of the SIP URI. 166 More specifically, the SED is the set of parameters that the outgoing 167 SBEs need to complete the call, and may include: 169 . A destination SIP URI 171 . A SIP proxy or ingress SBE to send the INVITE to, including 173 o Fully Qualified Domain Name (FQDN) 175 o Port 177 o Transport Protocol (UDP [9], TCP [10], and TLS [11]) 179 . Security Parameters, including 181 o TLS certificate to use 183 o TLS certificate to expect 185 o TLS certificate verification setting 187 . Optional resource control parameters such as 189 o Limits on the total number of call initiations to a peer 191 o Limits on SIP transactions per second 193 3.4. Call Routing 195 Call routing is the set of processes and rules used to route a call 196 and any subsequent mid-dialog SIP requests to their proper (SIP) 197 destination. More generally, call routing can be thought of as the 198 set of processes and rules, which are used to route a real-time 199 session to its termination point. 201 3.5. PSTN 203 The term "PSTN" refers to the Public Switched Telephone Network. In 204 particular, the PSTN refers to the collection of interconnected 205 circuit-switched voice-oriented public telephone networks, both 206 commercial and government-owned. In general, PSTN terminals are 207 addressed using E.164 numbers; various dial-plans (such as emergency 208 services dial-plans), however, some applications may not directly use 209 E.164 numbers. 211 3.6. IP Path 213 For purposes of this document, an IP path is defined to be a sequence 214 of zero or more IP router hops. 216 3.7. Peer Network 218 This document defines a peer network as the set of SIP user agents 219 (UAs) (customers) that are associated with a single administrative 220 domain and can be reached via some IP path. Note that such a peer 221 network may also contain end-users who are located on the PSTN (and 222 hence may also be interconnected with the PSTN), as long as they are 223 also reachable via some IP path. 225 3.8. Service Provider 227 A Service Provider (SP) is defined to be an entity that provides 228 layer 3 (IP) transport of SIP signaling and media packets. Example 229 services may include, but are not limited too, Ethernet Private Line 230 (EPL), Frame Relay, and IP VPN. An example of this may be an 231 Internet Service Provider (ISP). 233 3.9. SIP Service Provider 235 A SIP Service Provider (SSP) is an entity that provides session 236 services utilizing SIP signaling to its customers. In the event that 237 the SSP is also a function of the SP, it may also provide media 238 streams to its customers. Such an SSP may additionally be peered 239 with other SSPs. An SSP may also interconnect with the PSTN. An SSP 240 may also be referred to as an Internet Telephony Service Provider 241 (ITSP). While the terms ITSP and SSP are frequently used 242 interchangeably, this document and other subsequent SIP peering 243 related documents should use the term SSP. SSP more accurately 244 depicts the use of SIP as the underlying layer 5 signaling protocol. 246 4. Peering 248 While the precise definition of the term "peering" is the subject of 249 considerable debate, peering in general refers to the negotiation of 250 reciprocal interconnection arrangements, settlement-free or 251 otherwise, between operationally independent service providers. 253 This document distinguishes two types of peering, Layer 3 Peering and 254 Layer 5 peering, which are described below. 256 4.1. Layer 3 Peering 258 Layer 3 peering refers to interconnection of two service providers' 259 networks for the purposes of exchanging IP packets which destined for 260 one (or both) of the peer's networks. Layer 3 peering is generally 261 agnostic to the IP payload, and is frequently achieved using a 262 routing protocol such as Border Gateway Protocol (BGP) [6] to 263 exchange the required routing information. 265 An alternate, perhaps more operational definition of layer 3 peering 266 is that two peers exchange only customer routes, and hence any 267 traffic between peers terminates on the peer's network or the peer's 268 customer's network. 270 4.2. Layer 5 Peering 272 Layer 5 (Session) peering refers to interconnection of two SSPs for 273 the purposes of routing real-time (or quasi-real time) call signaling 274 between their respective customers using SIP methods. Such peering 275 may be direct or indirect (see Section 4.2.1 and Section 4.2.2 276 below). Note that media streams associated with this signaling (if 277 any) are not constrained to follow the same set of IP paths. 279 4.2.1. Direct Peering 281 Direct peering describes those cases in which two SSPs peer without 282 using an intervening layer 5 network. 284 4.2.2. Indirect Peering 286 Indirect, or transit, peering refers to the establishment of either a 287 signaling and media path or signaling path alone via one (or more) 288 layer 5 transit network(s). In this case it is generally required 289 that a trust relationship is established between the originating SSP 290 and the transit SSP on one side; and, between the transit SSP and the 291 termination SSP on the other side. 293 4.2.3. On-demand Peering 295 SSPs are said to peer on-demand when they are able to exchange SIP 296 traffic without any pre-association prior to the origination of a 297 real-time transaction (like a SIP message) between the domains. Any 298 information that needs to be exchanged between domains in support of 299 peering can be learned through a dynamic protocol mechanism. On- 300 demand peering can occur as direct or indirect. 302 4.2.4. Static Peering 304 SSPs are said to peer statically when pre-association between 305 providers is required for the initiation of any real-time 306 transactions (like a SIP message). Static peering can occur as 307 direct or indirect. An example of static peering is a federation. 308 Each of the peers within the federation must first agree on a common 309 set of rules and guidelines for peering, thus pre-associating with 310 each other prior to initiating session requests. 312 4.3. Functions 314 The following are terms associated with the functions required for 315 peering. 317 4.3.1. Signaling Function 319 The Signaling Function (SF) performs routing of SIP requests for 320 establishing and maintaining calls, and to assist in the discovery or 321 exchange of parameters to be used by the Media Function (MF). The SF 322 is a capability of SIP processing elements such as a SIP proxy, SBE, 323 and user agent. 325 4.3.2. Media Function 327 The Media Function (MF) performs media related functions such as 328 media transcoding and media security implementation between two SSPs. 329 The MF is a capability of SIP session associated media end-points 330 such as a DBE and user agent. 332 4.3.3. Look-Up Function 334 The Look-Up Function (LUF) provides a mechanism for determining for a 335 given request the target domain to which the request should be 336 routed. An example of the LUF is an ENUM [4] look-up or a SIP INVITE 337 request to a SIP proxy providing redirect responses for peers. 339 In some cases, some entity (usually a 3rd party or federation) 340 provides peering assistance to the originating SSP by providing this 341 function. The assisting entity may provide information relating to 342 direct (Section 4.2.1) or indirect (Section 4.2.2) peering as 343 necessary. 345 4.3.4. Location Routing Function 347 The Location Routing Function (LRF) determines for the target domain 348 of a given request the location of the SF in that domain and 349 optionally develops other SED required to route the request to that 350 domain. An example of the LRF may be applied to either example in 351 Section 4.3.3. Once the ENUM response or SIP 302 redirect is 352 received with the destination's SIP URI, the LRF must derive the 353 destination peer's SF from the FQDN in the domain portion of the URI. 355 In some cases, some entity (usually a 3rd party or federation) 356 provides peering assistance to the originating SSP by providing this 357 function. The assisting entity may provide information relating to 358 direct (Section 4.2.1) or indirect (Section 4.2.2) peering as 359 necessary. 361 5. Federations 363 A federation is a group of SSPs which agree to exchange calls with 364 each other via SIP, and who agree on a set of administrative rules 365 for such calls (settlement, abuse-handling, ...) and the specific 366 rules for the technical details of the peering. 368 The following provides examples of rules the peers of a federation 369 may agree to and enforce upon all participants: 371 . Common domain for all federation peers (e.g. 372 bob@peer1.federation.example.com) 374 . Codec rule (e.g. all peers must use the ITU-T G.711 codec [15]) 376 . Authentication preference (e.g. all peers must use TLS when 377 requesting to establish sessions with other peers) 379 . Transport protocol (e.g. all peers must use TCP) 381 . SIP address resolution mechanisms (e.g. all peers must use ENUM 382 for resolving TNs to SIP URIs) 384 Finally, note that an SSP can be a member of 386 o No federation (e.g., the SSP has only bilateral peering 387 agreements) 389 o A single federation 391 o Multiple federations 393 and an SSP can have any combination of bi-lateral and multi- 394 lateral (i.e., federated) peers. 396 6. Acknowledgments 398 Many of the definitions were gleaned from detailed discussions on the 399 SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, 400 Eli Katz, Gaurav Kulshreshtha, Otmar Lendl, Jason Livingood, 401 Alexander Mayrhofer, Jean-Francois Mule, Jonathan Rosenberg, David 402 Schwartz, Richard Shockey, Henry Sinnreich, Richard Stastny, Hannes 403 Tschofenig, Dan Wing, John Elwell, and Adam Uzelac all made valuable 404 contributions to early versions of this document. Patrik Faltstrom 405 also made many insightful comments to early versions of this draft. 407 7. Security Considerations 409 This document introduces no new security considerations. However, it 410 is important to note that session peering, as described in this 411 document, has a wide variety of security issues that should be 412 considered in documents addressing both protocol and use case 413 analysis. 415 8. IANA Considerations 417 This document has no IANA actions. 419 9. Informative References 421 [1] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 422 specifying the location of services (DNS SRV)", RFC 2782, 423 February 2000. 425 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 426 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 427 Session Initiation Protocol", RFC 3261, June 2002. 429 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 430 Four: The Uniform Resource Identifiers (URI)", RFC 3404, 431 October 2002. 433 [4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 434 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 435 Application (ENUM)", RFC 3761, April 2004. 437 [5] International Telecommunications Union, "The International 438 Public Telecommunication Numbering Plan", ITU-T Recommendation 439 E.164, 02 2005. 441 [6] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 442 (BGP-4)", RFC 4271, January 2006. 444 [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 445 "RTP: A Transport Protocol for Real-Time Applications", RFC 446 3550, July 2003. 448 [8] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol 449 Extended Reports (RTCP XR)", RFC 3611, November 2003. 451 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 452 Considerations Section in RFCs", BCP 26, RFC 2434, October 453 1998. 455 [10] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 456 4346, April 2006. 458 [11] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 459 1980. 461 [12] Postel, J., "DoD Standard Transmission Control Protocol", RFC 462 761, January 1980. 464 [13] Plummer, David C., "An Ethernet Address Resolution Protocol", 465 RFC 826, November 1982. 467 [14] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines 468 for DiffServ Service Classes", RFC 4594, August 2006. 470 [15] ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM) 471 of voice frequencies. 473 Author's Addresses 475 Daryl Malas 476 CableLabs 477 858 Coal Creek Circle 478 Louisville, CO 80027 479 USA 480 Email: d.malas@cablelabs.com 482 David Meyer 483 Email: dmm@1-4-5.net 485 Intellectual Property Statement 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Disclaimer of Validity 511 This document and the information contained herein are provided on an 512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 514 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 515 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 516 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 519 Copyright Statement 521 Copyright (C) The IETF Trust (2008). 523 This document is subject to the rights, licenses and restrictions 524 contained in BCP 78, and except as set forth therein, the authors 525 retain all their rights. 527 Acknowledgment 529 Funding for the RFC Editor function is currently provided by the 530 Internet Society.