SPEERMINT Working Group D. Malas, Ed. Internet-Draft Level 3 Communications Intended status: Informational D. Meyer, Ed. Expires: February 2008 August 10, 2007 SPEERMINT Terminology draft-ietf-speermint-terminology-10.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 10, 2008. Abstract This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). Table of Contents 1. Introduction...................................................2 2. SPEERMINT Context..............................................3 3. General Definitions............................................4 3.1. Signaling Path Border Element.............................4 3.2. Data Path Border Element..................................4 3.3. Session Establishment Data................................4 3.4. Call Routing..............................................5 3.5. PSTN......................................................5 Malas & Meyer Expires February 10, 2008 [Page 1] Internet-Draft SPEERMINT Terminology August 2007 3.6. IP Path...................................................6 3.7. Peer Network..............................................6 3.8. Service Provider..........................................6 3.9. SIP Service Provider......................................6 3.10. Internet Telephony Service Provider......................6 4. Peering........................................................6 4.1. Layer 3 Peering...........................................7 4.2. Layer 5 Peering...........................................7 4.2.1. Direct Peering.......................................7 4.2.2. Indirect Peering.....................................7 4.2.3. Assisted Peering.....................................7 4.2.4. On-demand Peering....................................8 4.2.5. Static Peering.......................................8 4.3. Functions.................................................8 4.3.1. Look-Up Function.....................................8 4.3.2. Location Function....................................8 4.3.3. Signaling Function...................................8 4.3.4. Media Function.......................................8 5. Federations....................................................8 6. Acknowledgments...............................................10 7. Security Considerations.......................................10 8. IANA Considerations...........................................10 9. Normative References..........................................10 Author's Addresses...............................................12 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................12 Copyright Statement..............................................13 Acknowledgment...................................................13 1. Introduction The term "Voice over IP Peering" (VoIP Peering) has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of Session Initiation Protocol (SIP [2]) call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. Session Peering for Multimedia Interconnect focuses on how to identify and route real-time sessions (such as VoIP calls) at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. Malas & Meyer Expires February 10, 2008 [Page 2] Internet-Draft SPEERMINT Terminology August 2007 This document introduces standard terminology for use in characterizing real-time session interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for non- voice or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the SPEERMINT Working Group. Section 3 provides the general definitions for real-time SIP based communication, with initial focus on the VoIP interconnect case, and Section 4 defines the terminology describing the various forms of peering. Finally, Section 5 introduces the concept of federations. 2. SPEERMINT Context Figure 1 depicts the general session interconnect context. Note that vertical axis in this figure describes the layering of identifiers, while the horizontal lines indicate working group scope. While the SPEERMINT working group is not limited (or coupled in any way) to the use of E.164 numbers, in the case shown here an E.164 number [5] is used as a key in an E.164 to Uniform Resource Identifier (URI) mapping (ENUM [4]). That URI is in turn used to retrieve a Naming Authority Pointer (NAPTR) record [3], which is in turn resolved into a SIP URI. Call routing is based on the resulting SIP URI. Note that the call routing step does not depend on the presence of an E.164 number. Indeed, the resulting SIP URI may no longer even contain any numbers of any type. In particular, the SIP URI can be advertised in various other ways, such as on a web page. E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in Domain Name System (DNS) | | | ENUM Working Group Scope =====+==================================================== | SPEERMINT Working Group Scope Lookup Discovery <--- Session Establishment Data (SED) SIP URI | | <--- Federation Detection, Policy | Lookup, and Service Location | | Hostname <--- Addressing and session establishment | | SPEERMINT Working Group Scope Malas & Meyer Expires February 10, 2008 [Page 3] Internet-Draft SPEERMINT Terminology August 2007 =====+==================================================== | Out of scope for the SPEERMINT Working Group | | <--- Lookup of A and AAAA in DNS | IP address | | <--- Routing protocols, ARP [14] etc. | MAC-address Figure 1: Session Interconnect Context Note that in Figure 1, Session Establishment Data (SED), is the data used to route a call to the called domain's ingress point (see Section 3.3 for additional detail). As illustrated in Figure 1, the ENUM Working Group is primarily concerned with the acquisition of SED while the SPEERMINT Working Group is focused on the use of such SED in routing session signaling requests. Importantly, the SED can be derived from ENUM (i.e., an E.164 DNS entry) or via any other mechanism available to theuser. Finally, note that the term "call" is being used here in the most general sense, i.e., call routing and session routing are used interchangeably. 3. General Definitions 3.1. Signaling Path Border Element A signaling path border element (SBE) provides signaling functions such as protocol inter-working (for example, H.323 to SIP), identity and topology hiding, and Call Admission Control (CAC) for a domain. Such an SBE is frequently (but need not be) deployed on a domain's border. 3.2. Data Path Border Element A data path border element (DBE) provides media-related functions such as deep packet inspection and modification, media relay, and firewall support under SBE control. As was the case with the SBE, a DBE is frequently deployed on a domain's border. 3.3. Session Establishment Data Session Establishment Data, or SED, is the data used to route a call to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record [1] that resulted from the resolution of the SED (i.e., a SIP URI). Malas & Meyer Expires February 10, 2008 [Page 4] Internet-Draft SPEERMINT Terminology August 2007 More specifically, the SED is the set of parameters that the outgoing SBEs need to complete the call, and may include: . A destination SIP URI . A SIP proxy to send the INVITE to, including o Fully Qualified Domain Name (FQDN) o Port o Transport Protocol (UDP/TCP/TLS [9/10/11]) . Security Parameters, including o TLS certificate to use o TLS certificate to expect o TLS certificate verification setting . Optional resource control parameters such as o Limits on the total number of calls to a peer o Limits on SIP transactions/second o Limits on the total amount of bandwidth used on a peering link o In addition, lower layer parameters (such as Differentiated Services Code Point (DSCP) [8] markings on SIP and/or media packets) might also be included. 3.4. Call Routing Call routing is the set of processes, rules, and SED used to route a call to its proper (SIP) destination. More generally, call routing can be thought of as the set of processes, rules and SED which are used to route a real-time session to its termination point. 3.5. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers; various dial-plans (such as emergency services dial-plans), however, may not directly use E.164 numbers. Malas & Meyer Expires February 10, 2008 [Page 5] Internet-Draft SPEERMINT Terminology August 2007 3.6. IP Path For purposes of this document, an IP path is defined to be a sequence of zero or more IP router hops. 3.7. Peer Network This document defines a peer network as the set of SIP user agent servers (UASs) [2] and SIP user agent clients (UACs) [2] (customers) that are controlled by a single administrative domain and can be reached via some IP path. Note that such a peer network may also contain end-users who are located on the PSTN (and hence may also be interconnected with the PSTN), as long as they are also reachable via some IP path. 3.8. Service Provider A Service Provider (or SP) is defined to be an entity that provides layer 3 (IP) transport of SIP signaling and media packets. An example of this may be an Internet Service Provider (ISP). 3.9. SIP Service Provider A SIP Service Provider (or SSP) is an entity that provides application level transport of SIP signaling to its customers. In the event that the SSP is also a function of the SP, it may also provide media streams to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A SSP may also interconnect with the PSTN. 3.10. Internet Telephony Service Provider An Internet Telephony Service Provider, or ITSP, is a synonym for SSP. While the terms ITSP and SSP are frequently used interchangeably, the SPEERMINT working group uses the term SSP. 4. Peering While the precise definition of the term "peering" is the subject of considerable debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. Malas & Meyer Expires February 10, 2008 [Page 6] Internet-Draft SPEERMINT Terminology August 2007 4.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers' networks for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as Border Gateway Protocol (BGP) [6] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange only customer routes, and hence any traffic between peers terminates on one of the peer's network. 4.2. Layer 5 Peering Layer 5 (Session) peering refers to interconnection of two service providers for the purposes of routing real-time (or quasi-real time) call signaling between their respective customers using SIP methods. Such interconnection may be direct or indirect (see Section 4.2.1 and Section 4.2.2 below). Note that media streams associated with this signaling (if any) are not constrained to follow the same set of IP paths. 4.2.1. Direct Peering Direct peering describes those cases in which two service providers interconnect without using an intervening layer 5 network. 4.2.2. Indirect Peering Indirect, or transit, peering refers to the establishment of either a signaling and media path or signaling path alone via one (or more) referral or transit network(s). In this case it is generally required that a trust relationship is established between the originating service provider and the transit network on one side, and the transit network and the termination network on the other side. 4.2.3. Assisted Peering In this case, some entity (usually a 3rd party or federation) provides peering assistance to either the originating or terminating SSP by providing one or more functions (see Section 4.3) assisting in the routing of SIP requests, the establishment of SIP dialogs, and sessions between one or more SSP's. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary. Malas & Meyer Expires February 10, 2008 [Page 7] Internet-Draft SPEERMINT Terminology August 2007 4.2.4. On-demand Peering Service providers are said to peer on-demand when they are able to exchange traffic without any pre-association prior to the origination of a real-time transaction (like a SIP message) between the domains. Any information that needs to be exchanged between domains in support of peering can be learned through a dynamic protocol mechanism. On- demand peering can occur as direct, indirect, or assisted. 4.2.5. Static Peering Service providers are said to peer statically when pre-association between providers is required for the initiation of any real-time transactions (like a SIP message). Static peering can occur as direct, indirect, or assisted. 4.3. Functions The following are terms associated with the functions required for peering. 4.3.1. Look-Up Function The Look-Up Function (LUF) provides a mechanism for querying an internal and/or external database, which maintains a list of SIP user names and associated peering domains. 4.3.2. Location Function The Location Function (LF) develops call routing data (CRD) by discovering the Signaling Function (SF), and SF's reachable host (IP Address and port). 4.3.3. Signaling Function The SF performs routing of SIP messages, to optionally perform termination and re-initiation of the call, and to assist in the discovery/exchange of parameters to be used by the Media Function (MF). 4.3.4. Media Function The MF performs media related functions such as media transcoding and media security implementation between two SSPs. 5. Federations A federation is a group of SSPs which agree to receive calls from each other via SIP, and who agree on a set of administrative rules Malas & Meyer Expires February 10, 2008 [Page 8] Internet-Draft SPEERMINT Terminology August 2007 for such calls (settlement, abuse-handling, ...) and the specific rules for the technical details of the interconnection. A federation may provide some or all of the following functionality: . Common static policies o Routing o Domain o Location o Next hop o Network-to-Network Interface (NNI) . Common dynamic policies o Congestion control o Codec preference o Authentication preference o Quality monitoring capabilities (e.g. RTP Control Protocol (RTCP) [12], RTCP Extended Reports (RTCP XR) [13]) . Policy management (enforcement) o Ad-hoc o Published in the DNS, or o Policy might also be managed by a federation entity . A federated ENUM root . Address resolution mechanisms . Session signaling (via federation policy) . Media streams (via federation policy) . Federation security policies . Interconnection policies . Other layer 2 and layer 3 policies Malas & Meyer Expires February 10, 2008 [Page 9] Internet-Draft SPEERMINT Terminology August 2007 . Security parameters . Optional resource control parameters Finally, note that a SSP can be a member of o No federation (e.g., the SSP has only bilateral peering agreements) o A single federation o Multiple federations and an SSP can have any combination of bi-lateral and multi- lateral (i.e., federated) interconnections. 6. Acknowledgments Many of the definitions were gleaned from detailed discussions on the SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Eli Katz, Gaurav Kulshreshtha, Otmar Lendl, Jason Livingood, Alexander Mayrhofer, Jean-Francois Mule, Jonathan Rosenberg, David Schwartz, Richard Shockey, Henry Sinnreich, Richard Stastny, Hannes Tschofenig, Dan Wing, and Adam Uzelac all made valuable contributions to early versions of this document. Patrik Faltstrom also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document introduces no new security considerations. However, it is important to note that session interconnect, as described in this document, has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [7]. 9. Normative References [1] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Malas & Meyer Expires February 10, 2008 [Page 10] Internet-Draft SPEERMINT Terminology August 2007 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [5] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 02 2005. [6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [8] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [11] Postel, J., "DoD Standard Transmission Control Protocol", RFC 761, January 1980. [12] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [13] Friedman, T., Caceres, R., Clark, A., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [14] Plummer, David C., "An Ethernet Address Resolution Protocol", RFC 826, November 1982. Malas & Meyer Expires February 10, 2008 [Page 11] Internet-Draft SPEERMINT Terminology August 2007 Author's Addresses Daryl Malas Level 3 Communications LLC 1025 Eldorado Blvd. Broomfield, CO 80021 USA Email: daryl.malas@level3.com David Meyer Email: dmm@1-4-5.net Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Malas & Meyer Expires February 10, 2008 [Page 12] Internet-Draft SPEERMINT Terminology August 2007 Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Malas & Meyer Expires February 10, 2008 [Page 13]