Network Working Group M. Bhatia Internet-Draft NexTone Communications Expires: August 30, 2006 February 26, 2006 Route Policy and Architecture in SIP Peering Environments draft-bhatia-sip-peering-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. 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 August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The purpose of this document is to help the IETF community understand the route architectures being used today in SIP based peering environments and to outline a set of requirements based on the same for discussion within the community. Bhatia Expires August 30, 2006 [Page 1] Internet-Draft sip-peering-route-policy February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Call Flow . . . . . . . . . . . . . . . . . . . . . . 4 4. Routing Architectures . . . . . . . . . . . . . . . . . . . . 5 4.1. Use of Edge Proxies and Session Border Controllers . . . . 6 5. Requirements for route policy and architecture for peering . . 6 5.1. Type of outgoing peer . . . . . . . . . . . . . . . . . . 7 5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Business Requirements . . . . . . . . . . . . . . . . . . 8 5.3.1. Cost or Profit . . . . . . . . . . . . . . . . . . . . 8 5.3.2. SLAs . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3.3. Bundling of calls for route determination purposes . . 8 5.4. Local Network Policy . . . . . . . . . . . . . . . . . . . 9 5.5. Regulatory Requirements . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informational References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Bhatia Expires August 30, 2006 [Page 2] Internet-Draft sip-peering-route-policy February 2006 1. Introduction The purpose of this document is to help the IETF community understand the route architectures being used today in SIP[1] based peering environments and to outline a set of requirements based on the same for discussion within the community. The document also provides an overview of the types of SIP service providers involved in peering for a typical SIP call and the policy, methods and architecture used for peering. 2. Terminology Each of the types of Service Providers defined below are wrt a subscriber who originates or terminates a SIP call, as shown in Figure 1. Service Provider (SP): We use the term Service Provider in this document to refer to a SIP Service Provider[3]. The individual types of SPs are defined below. Core SP: An SP which is responsible for applying the subscriber's policy for termination or origination services. The core SP is typically also the registrar for the user and/or is aware of the current A-O-R bindings[1] of the user. Access SP: An SP which acts as the first hop between the subscriber and the Core SP. Interconnect SP: An SP which is not the Core or Access SP and still lies in the call path. Origination SP: The Core SP for the call originator. Termination SP: The Core SP for the call termination. Application SP (ASP): A Core SP which does not provide the Access SP function. Downstream SP (also called downstream peer): Next hop SP wrt the direction of SIP dialog creation request. Upstream SP (also called upstream peer): Previous hop SP wrt the direction of SIP dialog creation request. Bhatia Expires August 30, 2006 [Page 3] Internet-Draft sip-peering-route-policy February 2006 Registry: A domain server which facilitates SIP peering indirectly by providing address location services and/or policy. Note that an SP may simultaneously perform more than one role identified above in a single SIP call and thereby be associated with more than one type above. In this document, where we analyze peering between SPs, we only look at the following case: The Origination SP is different from the Termination SP, except in the case outlined in Section 5.5. Session Border Controller: A SIP Back to Back UA[1] typically deployed at the SIP network edge to enforce peering policies. 3. General Call Flow +---+ /~~~~~~\ /~~~~\ /~~~~~~~\ /~~~~\ /~~~~~~\ +---+ | O |->(Access-O)->(Core-O)->(Interconn)->(Core-T)->(Access-T)->| T | +---+ \~~~~~~/ \~~~~/ \~~~~~~~/ \~~~~/ \~~~~~~/ +---+ Figure 1: General Call Flow for Peering Figure 1 describes a functional rather than a physical setup for a complete peer-to-peer call. All SPs except the Core SPs are considered optional for the purposes of this document. The arrows indicate SIP messaging only. The call is originated at calling party "O", (called the "Origination" in this document) and terminates at called party "T" (called the "Termination" in this document). T may be a subscriber, contact center, E911 operator etc. The first hop and the last hop of the call in Figure 1 pass through SPs providing L5 (in our case SIP) access to the origination and termination and are called Access-O and Access-T respectively. In most cases these SPs will also provide the physical access to the origination and termination devices. The Access SP function is not optional. While a separate Access SP may not exist, the function may be absorbed by the corresponding Core SP. One point to note about the Access SP is that there may be more than one Access SP when terminating calls to the subscriber. This choice is typically dictated by the subscriber or subscriber policy at the Core SP. The Core SP may fork or hunt the subscriber using these Access SPs. In Figure 1, the origination's Core SP is referred to as "Core-O" SP Bhatia Expires August 30, 2006 [Page 4] Internet-Draft sip-peering-route-policy February 2006 and the terminations Core SP is referred to as "Core-T" SP. Unlike the Access SP, the Interconnect SP function is truly optional. Most Interconnect SPs exist because it is operationally or commercially difficult for the Core SPs to connect directly. Some Interconnect SPs also provide "one point connectivity" where they provide value added services like one point of managed physical access, billing and interworking. There may be more than one Interconnect SP in the full call flow. An Interconnect SP may also sit between the Access SPs and the Core SP, essentially making the Core SP lower layer agnostic (the Core SP can be equated more with an ASP at that point). Similar to the available choice of Access SPs, there may be more than one Interconnect SP to which the Core SP could choose to hand-off the call. However unlike the case of Access SPs, this choice is strictly dictated by the core SPs local policy. 4. Routing Architectures The general call flow depicted above yields the following general classification of peering architectures in use: 1. Direct Peering: Direct Peering is the peering between Core-O and Core-T without any other SIP SP in the middle. It typically takes one of two forms depending on how some part of the peering policy may be provisioned: Federation: A federation is typically a set of SPs which are terminating calls to each other using some well known mechanisms for settlement, address location and some other common administrative policies. In most cases the peering SPs are connected to a trusted private network and trust all calls terminating on them over this network. Federations typically use ENUM as the registry database (owned by the federation or a trusted third party) to provide address location services and applications like number portability. Other aspects of the routing policy (as described in Section 5) are implemented using edge proxies or session border controllers (Section 4.1). Local Policy: The peering SPs may provision routes to each other using local policy and only accept calls from partners provisioned in local policy. Bhatia Expires August 30, 2006 [Page 5] Internet-Draft sip-peering-route-policy February 2006 2. Peering through Interconnect SPs: In most cases this model is used when the Core-O SP prefers not to directly connect to a Core-T SP due to business reasons. For example, the Core-T SP may be too small, making the relationship expensive for the Core-O SP or vice-versa. An Interconnect SP may also be used between the access SPs and the corresponding Core SPs due to similar reasons. It should be worth noting that an Interconnect SP may use an ENUM Registry database to provide address location services as well. This could be in conjunction with the simultaneous use of ENUM at other points of the call for address location (usually Private ENUM[3] is used). 3. Access Peering: Access Peering may typically be used when the subscriber roams to a place the Core SP does not offer service or is using a Layer 5 (SIP) aware SP to connect to its Core SP (which may be an ASP or content provider). The location of the Core SP is usually based on DNS. In this case the Access SP is trying to locate the originations Core SP rather than the termination's Core SP (compare with the use of ENUM). 4.1. Use of Edge Proxies and Session Border Controllers Edge Proxies / Session Border Controllers are quite widely used for implementing the route policies in SIP peering environments (as described in this document). Functions of SBCs not related to route policy are not the subject of this document. In some cases, the Edge Proxy/SBC may also use media steering (or routing) when peering with another SP in which case media associated with the session is coupled along with the path taken by SIP signaling (the peering SPs generally need to have a common understanding on required network resources and QoS for media). While there may be other requirements for coupling media and signaling, we will only look at those affecting route policy in this document. See Section 5.3.2 for these requirements. Unless required for another application (like QoS or regulatory), media steering may be avoided, especially when SPs route policy is not affected by the information gathered through media examination or the same information is available through other reliable means. 5. Requirements for route policy and architecture for peering Bhatia Expires August 30, 2006 [Page 6] Internet-Draft sip-peering-route-policy February 2006 In this section we look at requirements and factors which affect route policy and architecture used for peering. We first enumerate some of the factors and then do a more in-depth analysis: 1. Type of outgoing peer: For example, whether the call is handed off to the Core-T SP or an Interconnect SP. 2. Addressing: Whether the address of record of the termination is an E.164 address or a generic AOR (e.g foo@bar.com) 3. Business reasons: For example, any costs an SP must pay to terminate the call through a given peer. The SP may also be required to fulfill any service level agreements on behalf of subscriber policy or level of service. 4. Local Network Policy: A SP may have to abide by local policy applicable to network assets, bandwidth engineering, security etc. 5. Regulatory requirements: For example, in the U.S Equal Access and Lawful Intercept may govern some aspects of call routing. The priority of the call, for example E911 or GETS (Government Emergency Telecommunications Service) calls in the U.S. Other factors, for example, (i) physical device (legacy/wireless/ cell/sip) used by termination or origination or (ii) the type of incoming peer (Core-O or Interconnect SP) do not seem to affect route policy to a great extent. We now investigate some of these in greater detail. 5.1. Type of outgoing peer The type of outgoing peer (Core v/s Interconnect) affects the policy in at least two ways: First, it affects how an SP would handle exception situations when attempting to terminate a call to the peer. For example, if the call fails, the SP could attempt to hunt in case the peer was an Interconnect SP. This may not be necessary when the peer is the termination's core-T SP (who may know the subscriber's busy status). Second, this also affects how address location may be done. In most cases when terminating calls directly to the termination's Core SP, ENUM is viable. This is less the case when handing off the calls to an Interconnect SP. 5.2. Addressing The type of A-O-R for the termination may also affect what kind of address location service is used. Address location is done typically based on the following four characteristics of the termination's AOR. In each case, we list the most common address location method used. Bhatia Expires August 30, 2006 [Page 7] Internet-Draft sip-peering-route-policy February 2006 1. Full E.164: ENUM or SP's local policy may be used. 2. E.164 prefixes: SPs local policy is generally used. 3. Full A-O-R: This is rarely used for routing in a peering environment. 4. Domain of A-O-R: DNS SRV or SPs local policy may be used. 5.3. Business Requirements The SPs business requirements have the most decided impact on the route policy and architecture. We have tried to break down the business requirements in the following categories and the methods used in each case: 5.3.1. Cost or Profit This is applicable most of the time when a call is being handed off to an Interconnect network and there are multiple choices. The SP will try to prioritize "routes" or use other criteria like "time of day routing" based on business agreements established with the peers and/or known traffic patterns to the "region" where the termination belongs. 5.3.2. SLAs There are several kinds of SLAs which an SP may have either with the subscriber or the peer handing off the call to the SP in question. Here we will briefly describe QoS and Security based SLAs. 5.3.2.1. QoS An SP may use one or more measures of network quality, for example ASR (Answer Seizure Ratio)[4], PDD (Post Dial Delay) or media information (like packet loss, jitter, latency, MOS[5]) to choose between different peers for call handoff. 5.3.2.2. Security The capabilities of downstream peers to transmit user identity[2] securely, encrypt signaling (e.g TLS) and help in SPAM prevention may also be used to determine which peer to hand off the call to. 5.3.3. Bundling of calls for route determination purposes In some cases the downstream peer may require grouping of calls based on service classes or similar criteria. SP peers may pass this information towards each other using identifiers like CIC codes, Trunk Groups etc. These identifiers are then interpreted as service identifiers or route identifiers in the SP network for routing. Bhatia Expires August 30, 2006 [Page 8] Internet-Draft sip-peering-route-policy February 2006 5.4. Local Network Policy Local network policy related to admission control, for example, policies related to network and/or link bandwidth, equipment capacity/scale etc may affect which peer(s) are chosen for call handoff. 5.5. Regulatory Requirements Each country generally has regulatory requirements equivalent to E911, CALEA or Equal Access. In some cases an SP may also be required to satisfy these requirements. For example Equal Access is a LEC (Local Exchange Carrier) requirement and an SP operating as an LEC may be required to allow the subscriber his/her choice of IXC (IntereXchange Carrier) for certain set of calls. In essence, these requirements may affect route policy for peering where the downstream peer is chosen based on origination's policy. In this case, the Core-O and Core-T may be one and the same SP who peer through an Interconnect SP of the origination's choice. Regulatory requirements may generally lead to calls being blocked or routed through specific paths as well. It is quite possible that regulatory requirements will affect a small percentage of SIP based peering in the future. 6. Security Considerations 7. IANA Considerations This document has no IANA considerations. 8. Acknowledgements Special thanks to Andrew Colby and Bob Natale for their valuable comments on this draft version. 9. References 9.1. Normative References [1] 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. Bhatia Expires August 30, 2006 [Page 9] Internet-Draft sip-peering-route-policy February 2006 [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", I-D draft-ietf-sip-identity-06, October 2005. [3] Meyer, D., "SPEERMINT Requirements and Terminology", I-D draft-ietf-speermint-reqs-and-terminology-00, February 2006. 9.2. Informational References [4] "ITU E.411 International Network Management", March 2000. [5] "ITU P.862 Perceptual Evaluation of Speech Quality (PESQ)", February 2001. Bhatia Expires August 30, 2006 [Page 10] Internet-Draft sip-peering-route-policy February 2006 Author's Address Medhavi Bhatia NexTone Communications 101 Orchard Ridge Drive Gaithersburg, MD 20878 US Email: mbhatia@nextone.com Bhatia Expires August 30, 2006 [Page 11] Internet-Draft sip-peering-route-policy February 2006 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. 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. Bhatia Expires August 30, 2006 [Page 12]