Internet Draft A.Uzelac SPEERMINT Global Crossing Expires: March 2007 October 16, 2006 SIP Peering Use Case for VSPs draft-uzelac-speermint-use-cases-00.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. This document may only be posted in an Internet-Draft. 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 March 16, 2007. Uzelac Expires March 16, 2007 [Page 1] Internet-Draft draft-uzelac-speermint-use-cases September 2006 Abstract This document describes the typical interconnection scenarios for SIP peering within varying contexts. In all the scenarios, two or more administrative domains have some pre-established agreement that permits both signaling and media to traverse the network boundary. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................2 3. Assumptions....................................................3 4. Background for Use Cases.......................................3 5. Use Cases......................................................4 5.1. Proxy(o) to SBC(o) to Proxy(t)............................4 5.2. Proxy(o) to SBC(o) to SBC(t) to Proxy(t)..................5 5.3. Proxy(o) to SBC(T) to SBC(T) to Proxy(t)..................7 5.4. Proxy(o) to SBC(o) to SBC(T) to SBC(T) to SBC(t) Proxy(t).8 6. Security Considerations........................................9 7. IANA Considerations............................................9 References.......................................................10 Normative References..........................................10 Informative References........................................10 Author's Addresses...............................................12 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................12 Copyright Statement..............................................13 Acknowledgment...................................................13 1. Introduction The intention of this document is to depict the current SIP Peering scenarios of the VoIP Service Provider. (VSP) The use cases involve VSPs as both a supplier of VoIP directly to end users, and within an Inter-Exchange Carrier (IXC) context, meaning providing SIP origination and termination services between VSPs. 2. Terminology o VoIP Service Provider (VSP): - This term VoIP Service Provider is consistent with SPEERMINT Terminology [12]. The individual types of VSPs are defined below. o Originating VSP - VSP(o): A VSP where the calling party resides. o Terminating VSP - VSP(t): A VSP where he called party resides. Uzelac Expires March 16, 2007 [Page 2] Internet-Draft draft-uzelac-speermint-use-cases September 2006 o Transit VSP - VSP(T): A VSP which is responsible for transiting sessions from one VSP to another VSP. The Transit VSP is typically not the registrar for the user. A Transit VSP can also be an Access VSP. o Session Border Controller (SBC): A SIP Intermediary device implemented as a B2BUA. [17] 3. Assumptions o All call flows are implemented in a collapsed signaling and media at the administrative boundary. The media flows are symmetrical across the boundary. o Transcoding, if required, is done at first point of recognized media incompatibility. o There is assumed IP reachability between network elements within administrative domain, as well as those network session border elements that "straddle" boundaries of both administrative domains. o There is no assumption of private (RFC1918) or public address space being used. 4. Background for Use Cases In the VSP interconnection scenarios illustrated in this document, the VoIP network border is "ring-fenced" with Session Border Controllers. As noted in [17], there are many functions that a SBC performs at the border of the VoIP network. It is important to understand the trust boundaries of the interconnection VSP administrative domains. Figure 1 shows the trust boundaries between the different networks that exchange traffic. Uzelac Expires March 16, 2007 [Page 3] Internet-Draft draft-uzelac-speermint-use-cases September 2006 VSP Core Network Operator's Interconnection +---Untrusted Domain--++---Trusted Domain---++---Untrusted Domain--+ ,-----. ,-------. ,-----. ,' `. ,-' `-. ,' `. / \ /-----\ /-----\ / \ ( VSP-1 )<------>| SBC |+-------+| MGW |<----->( PSTN ) \ / \--+--/ \ / \--+--/ \ / `. ,' / | \ / | \ `. ,' '-----' ; | \_ / | : '-----' : | / \ | ; ,-----. \ | / \ | / ,-----. ,' `. \ | / \ | / ,' `. / \ /--+--+---------+/--+--\ / \ ( VSP-2 )<------>| SBC | | SBC |<----->( VSP-3 ) \ / \-----/ \-----/ \ / `. ,' ' ' `. ,' '----'' \----------/ '----'' Figure 1 VSP Core Network In the following use cases there are subtle, but significant differences to the interconnection design. Administrative domains are interconnected by one or more Session Border Controllers (SBC) that are Back-to-Back User Agents (B2BUA). The SBC facilitates, among other functions, demarcation between the interconnected administrative domains. This is mostly done between VSPs, but there are instances of multiple administrative domains within a single VSP. The illustration of the MGW<->PSTN interconnect is noted as out of scope for this document, but shown to as it's part of the "untrusted" domain. NOTE: The SBC performs anonymizing services where all identifying information on Alice is removed. The anonymizing service is not related to privacy for the calling or called party, rather topology hiding and network abstraction. The SBC may also identify the need to perform codec media conversion (transcoding), if required to complete the call. 5. Use Cases 5.1. Proxy(o) to SBC(o) to Proxy(t) In this type of interconnection scenario, the SBC is owned and operated within the originating administrative domain. Uzelac Expires March 16, 2007 [Page 4] Internet-Draft draft-uzelac-speermint-use-cases September 2006 1. The proxy of origination performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 2. The result of the query will be a SBC that is directly interconnected to the terminating domain. 3. Proxy will signal the SBC. 4. The SBC performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 5. The result of this query is the Proxy server within VSP(t)'s network. 6. SBC signals the proxy. +-----Orig Domain--------+---Term Domain--+ +--------+ | +--------+ |ENUM/DNS| | |ENUM/DNS| | Proxy | | | Proxy | +--------+ | /+--------+ (1) / | (4)/ /(2) |/ (5) +-----+ +-----+ / +-----+ |Proxy|---(3)----|SBC |----(6)--|Proxy| +-----+ +-----+ +-----+ | | | | | | | | +--+ +--+ |UA| |UA| +--+ +--+ Figure 2 Proxy(o) to SBC(o) to Proxy(t) 5.2. Proxy(o) to SBC(o) to SBC(t) to Proxy(t) Multiple SBCs are implemented in this interconnection scenario. The SBCs are operated within different administrative domains. 1. The proxy within the originating domain performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. Uzelac Expires March 16, 2007 [Page 5] Internet-Draft draft-uzelac-speermint-use-cases September 2006 2. The next-hop would be one of possibly many SBCs that are interconnected with the VSP(t). 3. Proxy signals SBC1. 4. The SBC1 performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. In this scenario, SBC1 queries within the terminating network's administrative domain. 5. The result of this query is VSP(t)'s SBC. 6. SBC1 would them forward the signaling to the appropriate SBC within VSP(t), in this case SBC2. 7. SBC2 performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 8. The result of this query is Proxy in VSP(t). 9. SBC2 signals Proxy +-----Orig Domai -----++-------Term Domain--- --------+ | _____+--------+ +--------+ | / |ENUM/DNS| |ENUM/DNS| | / ----| Proxy | | Proxy | | / / +--------+ +--------+ | (4) / | | | (1) | | / (5) |(7)(8) | (2) | / / | | | +-----+ +----+/ / +----+ +-----+ |Proxy|---(3)-- |SBC |--/ |SBC |--(9 --|Proxy| +-----+ | |-----(6)----| | +-----+ | +----+ +----+ | | | | | | | | | | | | | +--+ +--+ |UA| |UA| +--+ +--+ Figure 3 Proxy(o) to SBC(o) to SBC(t) to Proxy(t) Uzelac Expires March 16, 2007 [Page 6] Internet-Draft draft-uzelac-speermint-use-cases September 2006 5.3. Proxy(o) to SBC(T) to SBC(T) to Proxy(t) In this interconnection scenario, three VSPs are involved in the call flow. There is a VSP of origination referred to as VSP(o). There is also a terminating VSP, referred to as VSP(t). In this use case, VSP(o) does not have a direct interconnection, contractual agreement or any way to directly send calls to VSP(t). In this case a third VSP provides transit services. This VSP is referred to as VSP(T). This method of communication is depicted in the figure below. +----VSP(o)------+-----VSP(T)-------+---VSP(t)------+ +--Orig Domain---+--Transit Domain--+--Term Domain--+ | | _____+--------+ +--------+ +--------+ | / |ENUM/DNS| |ENUM/DNS| |ENUM/DNS| | / ----| Proxy | | Proxy | | Proxy | | / / +--------+ +--------+ +--------+ | (7) / (1) | |(4) | | / (8) | (2) | | (5) | / / +-----+ +-----+ +----+-/ / |Proxy|----(3)---| SBC1|--(6)--|SBC2|---/ +-----+ +-----+ +-----+ +----+----(9)---|Proxy| | | | +-----+ | | | | | | | | | | +--+ +--+ |UA| |UA| +--+ +--+ Figure 4 Proxy - SBC-SBC - Proxy 1. The proxy within the originating domain performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 2. The next-hop would be one of possibly many SBCs that border with VSP(T), but is owned and operated by VSP(o). 3. The proxy in VSP(o) signals SBC1 4. SBC1 performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. This process occurs within VSP(T). 5. The result of this query would be SBC2 that is also under the administrative responsibility of VSP(T). Uzelac Expires March 16, 2007 [Page 7] Internet-Draft draft-uzelac-speermint-use-cases September 2006 6. SBC1 signals SBC2. 7. Another separate next-hop route determination process will occur within VSP(t). 8. The result is the terminating proxy. 9. SBC2 signals terminating proxy. 5.4. Proxy(o) to SBC(o) to SBC(T) to SBC(T) to SBC(t) Proxy(t) As in the interconnection scenario depicted in section 5.3. , three VSPs are involved in the call flow. The proxy within the originating domain performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. The next-hop would be one of possibly many SBCs that border with VSP(T), but is owned and operated by VSP(o). The SBC performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. The result of this query would be the SBC that is under the administrative responsibility of VSP(T). A distinctly separate next- hop route determination process will occur within VSP(T) that may take into account some originating information, like VSP(o)'s SBC. The initial SBC in VSP(T) performs a next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. The result would be a second SBC within VSP(T) that is interconnected to VSP(o). This second SBC performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. The result of this query would be one of possibly many SBCs within the administrative responsibility of VSP(t). +----VSP(o)-------+-----VSP(T)-------+---VSP(t)------+ +--Orig Domain----+--Transit Domain--+--Term Domain--+ | | +-----+ +-----+-----+ +-----+-----+ +-----+ |Proxy|----| SBC | SBC |------| SBC | SBC |---|Proxy| +-----+ +-----+-----+ +-----+-----+ +-----+ | | | | | | | | | | +-------+ | | | | Proxy | | +--+ +-------+ +--+ |UA| |UA| +--+ +--+ Uzelac Expires March 16, 2007 [Page 8] Internet-Draft draft-uzelac-speermint-use-cases September 2006 6. 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. 7. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. Uzelac Expires March 16, 2007 [Page 9] Internet-Draft draft-uzelac-speermint-use-cases September 2006 References Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [3] 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. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [7] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004. [8] Peterson, J., "Address Resolution for Instant Messaging and Presence",RFC 3861, August 2004. [9] Peterson, J., "Telephone Number Mapping (ENUM) Service Registration for Presence Services", RFC 3953, January 2005. [10] ETSI TS 102 333: " Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Gate control protocol". [11] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. Informative References [12] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint- terminology-06 (work in progress), May 2006. Uzelac Expires March 16, 2007 [Page 10] Internet-Draft draft-uzelac-speermint-use-cases September 2006 [13] Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP Interconnection", draft-ietf-speermint-requirements-00.txt, June 2006. [14] Mahy, R., "A Minimalist Approach to Direct Peering", draft- mahy-speermint-direct-peering-00.txt, June 19, 2006. [15] Penno, R., et al., "SPEERMINT Routing Architecture Message Flows", draft-ietf-speermint-flows-00.txt", August 2006. [16] Lee, Y., "Session Peering Use Case for Cable", draft-lee- speermint-use-case-cable-00.txt, June, 2006. [17] Camarillo, G. "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", draft-camarillo- sipping-sbc-funcs-04.txt, June, 2006. [18] Habler, M., et al., "A Federation based VOIP Peering Architecture", draft-lendl-speermint-federations-03.txt, September 2006. [19] Mahy, R., "A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services", draft-ietf- enum-im-service-00 (work in progress), March 2006. [20] Haberler, M. and R. Stastny, "Combined User and Carrier ENUM in the e164.arpa tree", draft-haberler-carrier-enum-02 (work in progress), March 2006. [21] Livingood, J. and R. Shockey, "IANA Registration for an Enumservice Containing PSTN Signaling Information", draft-ietf- enum-pstn-04 (work in progress), May 2006. Uzelac Expires March 16, 2007 [Page 11] Internet-Draft draft-uzelac-speermint-use-cases September 2006 Author's Addresses Adam Uzelac Global Crossing 1120 Pittsford Victor Road PITTSFORD, NY 14534 USA Email: adam.uzelac@globalcrossing.com 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 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. Uzelac Expires March 16, 2007 [Page 12] Internet-Draft draft-uzelac-speermint-use-cases September 2006 Copyright Statement Copyright (C) The Internet Society (2006). 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. Uzelac Expires March 16, 2007 [Page 13]