DRINKS Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track Expires: January 4, 2008 July 4, 2008 Location Routing Function Requirements draft-kaplan-drinks-lrf-requirements-00 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/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 January 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Kaplan Expires January 4, 2007 [Page 1] LRF Protocol Requirements July 2008 Abstract This document describes the requirements for a Location Routing Function Protocol, for inter and intra-domain SIP session routing. Table of Contents 1. Introduction..........................................2 2. Terminology...........................................3 3. Applicability.........................................3 4. Definitions...........................................4 5. Requirements..........................................4 6. Security Considerations...............................6 7. IANA Considerations...................................6 8. Acknowledgements......................................6 9. References............................................6 9.1. Normative References..................................6 9.2. Informative References................................6 Author's Address.............................................6 Intellectual Property Statement..............................7 Full Copyright Statement.....................................7 Acknowledgment...............................................7 1. Introduction As defined in [SPEERMINT-Architecture], there are generally two sets of problems when routing SIP requests through SIP Service Providers (SSP's): determining the final terminating SSP or domain which "owns" or provides service for the target identity, and determining how to reach that terminating SSP domain. The first problem, determining the terminating domain, is resolved by the "Look-Up Function" (LUF). The second problem is resolving the Session Establishment Data (SED) information necessary to actually route the request to the terminating domain resolved by the LUF, which is the role of the "Location Routing Function" (LRF). The LUF function may be performed, for example, by a Public ENUM resolution process, or a query to a Registry database, or a query to a private database which learns its data through such protocols as [ESPP] or SS7, or the terminating domain may even be indicated in the SIP Request to begin with. Regardless of how the LUF function is performed, and the identity of the terminating domain be determined, there is no reason to think that the local SSP has a direct SIP connection to the ultimate terminating domain. Indeed, such relationships are bound by business and legal restrictions, rather than IP reachability, Kaplan Expires - January 2008 [Page 2] LRF Protocol Requirements July 2008 and thus direct SIP reachability is highly unlikely. (for an excellent discussion on this topic, see [draft-lendl-background]) In addition, over the course of the past few years, the size and complexity of SIP Service Provider (SSP) networks have increased dramatically. The number of SIP nodes in the network, as well as the number of SIP peering connections, has increased to the point where static provisioning of SIP routing data is beginning to cause issues; issues in terms of the time required to add new routes, complexity in determining alternate or multi-path routes, and increasing errors in route paths due to human error. As more SSP nodes are added, more Enterprise SIP Trunks connected, and inter-SSP peering connections increased, the burden on SSP administrators will continue to increase, or the rate of new connections will decrease. Lastly, while a vast majority of current SIP use is comprised of E.164 numbers as the URI target identifiers, market forces are expected to drive the need for generic user@domain target URI addressing. Whether such use will continue to rely on SSPs for request routing is unknown, but it clearly represents an LRF issue if [RFC3263] direct-routing is not used. These issues are driving the need for a dynamic location routing protocol for SIP - one such protocol is Session Location Routing Protocol (SLRP), which is introduced in [SLRP]. This document identifies the requirements for such a protocol to perform the LRF function. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability This draft applies to [RFC3261] SIP request routing, in the context of SPEERMINT-defined SSP architectures. Kaplan Expires - January 2008 [Page 3] LRF Protocol Requirements July 2008 4. Definitions SSP: SIP Service Provider, the administrative entity providing SIP services utilizing SIP. Note that an SSP may be a traditional Service Provider, an Enterprise, or any administrative domain context. LUF: Look-Up Function, the functional step(s) necessary to determine for a given SIP request, which terminating domain it should be sent to. LRF: Location Routing Function, the functional step(s) necessary to determine for a given SIP request's terminating domain, the path to follow to reach the terminating domain. Routing: In the context of this document, it is forwarding of an out-of-dialog SIP request. SED: Session Establishment Data, the LUF and LRF data needed and used to route a SIP request to the next-hop(s) associated with reaching the terminating domain. SBE: Signaling-path Border Element, the SIP node that represents the logical boundaries between SSP domains (a.k.a., the signaling portion of an SBC, I-BCF, etc.). 5. Requirements R1: The LRF mechanism MUST provide a set of possible SIP next-hops and/or neighbor SSPs to route a SIP request through at a SIP layer, in order to reach the terminating domain. Note that this path may or may not follow the least-cost IGP and best BGP paths - they are orthogonal planes. R2: The LRF mechanism MUST support arbitrary connection topologies of SIP forwarding nodes and SSPs. R3: The LRF mechanism MUST support the ability to prevent loops, such that SIP requests routed using the LRF mechanism do not get pathologically routed back through the same forwarding path they previously traversed. R4: The LRF mechanism MUST provide reasonable scale, for an order of N SSP's (N is TBD). R5: The LRF mechanism MUST dynamically discover failures, and provide alternate routes around failures if such routes exist. Kaplan Expires - January 2008 [Page 4] LRF Protocol Requirements July 2008 R6: The LRF mechanism MUST support restricting the originating domains which can use or learn routes. R7: The LRF mechanism MUST allow a SSP to select routes to use based on its own selection preference criteria, which may or may not be the same criteria other SSPs use. R8: The LRF mechanism MUST support discriminating among multiple route choices based on flexible attributes. Flexible in the sense that future attributes may be defined in a backwards- compatible fashion. R9: The LRF mechanism MUST support SED routing data authentication, at least on a hop-by-hop or SSP-by-SSP basis. R10: The LRF protocol MUST support the ability to encrypt the SED routing data being exchanged. R11: The LRF mechanism MUST support flexible route target identifier types. Route target identifier types are the form of the key to the LRF lookup process. For example, a domain name is one type, an SSP identifier may be another, or an E.164 routing number may be a third. They should be flexible in the sense that future route target identifier types can be defined. R12: The LRF protocol MUST NOT impose any limitations with respect to physical implementation. Multiple instances of the protocol MUST be supportable on a single physical platform. R13: The LRF mechanism MUST NOT require an SSP to reveal internal SIP topology information to external SSPs. R14: The LRF mechanism MUST NOT prevent migration to or co- existence with [RFC3263] direct-routing. R15: The LRF mechanism SHOULD be resilient to transient node and path failures, such that they are protected against while not causing significant protocol churn. R16: The LRF mechanism SHOULD allow an administrator to choose whether to store the LRF data in one or more centralized database nodes, or distribute some or all of the data to SIP forwarding entities. Kaplan Expires - January 2008 [Page 5] LRF Protocol Requirements July 2008 6. Security Considerations This document does not define an actual mechanism - only requirements for one. Security requirements are contained within the Requirements section. 7. IANA Considerations This document makes no request of Internet Assigned Numbers Authority (IANA). 8. Acknowledgements Thanks to Don Troshynski, Rhys Arkins, Peter Commerford, Jeff Gibson, and Paul Erkkila for their input. 9. References 9.1. Normative References [RFC3261] 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. [RFC3263] Rosenberg, J., Schulzrinne, H., "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. 9.2. Informative References [SPEERMINT-Architecture] Penno, R., et al, "SPEERMINT Peering Architecture", draft-ietf-speermint-architecture-06.txt, May 2008. [ESPP] Cartwright, K., et al, "A Provisioning Protocol for ENUM- SIP Addressing Servers", draft-mule-peppermint-espp- protocol-00.txt, February 2008. [SLRP] Kaplan, H., "Session Location Routing Protocol (SLRP) Overview", work in progress. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - January 2008 [Page 6] LRF Protocol Requirements July 2008 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. Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires - January 2008 [Page 7]