DRINKS Working Group G. Schumacher Internet Draft Sprint Intended status: Informational H. Kaplan Expires: May 3, 2009 Acme Packet November 3, 2008 Look Up Function vs. Location Routing Function discussion draft-schumacher-drinks-luf-lrf-diff-01.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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 9, 2009. Abstract This document provides a comparison between the Look Up Function (LUF) and the Location Routing Function (LRF) as used for inter and intra-domain SIP session routing. It also develops the relationship between the two functions. This document is meant for discussion purposes only. Schumacher Expires May 3, 2009 [Page 1] Look Up Function vs. Location Routing Function discussion Nov 2008 Table of Contents 1. Introduction...................................................2 2. Review of SPEERMINT definitions................................2 3. Look Up Function...............................................3 3.1. LUF returning only a domain...............................3 3.2. Per-SSP LUF...............................................3 3.3. What the LUF does NOT provide.............................3 4. Location Routing Function......................................4 5. Interaction between LUF and LRF................................4 6. Reasons for separating LUF and LRF logical roles...............5 7. Security Considerations........................................6 8. IANA Considerations............................................6 9. Conclusions....................................................6 10. Acknowledgments...............................................6 11. References....................................................7 11.1. Normative References.....................................7 11.2. Informative References...................................7 1. Introduction In [SPEERMINT-Terms] the definition of the Look Up Function (LUF) and the Location Routing Function is provided. However in subsequent DRINKS discussions, the specific aspects attributable to each function, and the reasons for separation, are not clear. It has been easy to consider the operation of both of the functions when combined - a SIP address (URI) is provided to the LUF/LRF and a route to the next SSP is provided in response. However when each function is considered in situ relative to the other, the concept consistency breaks down into any number of different definitions. This also extends to where in a SSP's network the function(s) reside and what sort of data is utilized. In this document, the definition of each function will be expanded beyond [SPEERMINT-Terms] and [SPEERMINT-Arch]. Finally the relationship between the LUF and LUF will be developed to provide a clearer distinction of the functions. 2. Review of SPEERMINT definitions In [SPEERMINT-Terms] the definition of the LUF is: "The Look-Up Function (LUF) provides a mechanism for determining for a given request the target domain to which the request should be routed." [From Section 4.3.1] Schumacher Expires May 3, 2009 [Page 2] Look Up Function vs. Location Routing Function discussion Nov 2008 And in [SPEERMINT-Terms] the definition of the LRF is: "The Location Routing Function (LRF) determines for the target domain of a given request the location of the SF in that domain and optionally develops other SED required to route the request to that domain." [From Section 4.3.2] 3. Look Up Function There are two important points introduced by the SPEERMINT definition of the LUF. 3.1. LUF returning only a domain The LUF's role is to resolve the target domain for the final terminating SSP which will service the call request. For example, an originating SSP may need to resolve an out-of-dialog SIP request which identifies a destination E.164 phone number, and the LUF would resolve the phone number for number-portability and provide the resolved terminating SSP domain identifier. 3.2. Per-SSP LUF The LUF in a particular SSP will resolve an SSP target domain. However this target domain may or may not be the final terminating SSP domain identifier (e.g. the final destination of a call), and instead may require additional routing lookups in the resolved SSP. For example, an originating SSP may know the terminating Enterprise domain, because it was provided in the request-URI, and the LUF may be able to resolve that domain to a terminating SSP domain identifier, which provides terminating service to the Enterprise. Or an LUF may only have number or domain resolution knowledge for a specific set of terminating SSPs, and provide transit exit SSP domains for numbers/domains it does not know the real final terminating SSP for. [Note: whether this LUF model is appropriate, and how it works, is still to be determined] 3.3. What the LUF does NOT provide The LUF does not provide the entry or exit Signaling Function (SF) addresses required to actually route SIP requests through, nor Schumacher Expires May 3, 2009 [Page 3] Look Up Function vs. Location Routing Function discussion Nov 2008 provide the intermediate transit SSP domains to reach the resolved- to final terminating SSP. Such data is provided by the LRF. 4. Location Routing Function The LRF, in order to provide optimum routing of calls, uses the target SSP domain returned by the LUF, and applies SSP policy mechanisms to determine routing of the call from the SSP toward the hosting SSP's SF. Thus the role of the LRF is to resolve the path through which requests must be routed to reach a final SSP domain resolved by the LUF. For direct bi-lateral peering scenarios, where the final terminating SSP is directly adjacent to the local originating SSP performing the LUF and LRF queries, the LRF data is likely to be fairly static and fully known by the originating SSP. For multi-hop transit SSP scenarios, however, a protocol mechanism for learning and applying policies to build the data necessary for an LRF function is likely warranted. Such a protocol would need to take SSP connection privacy considerations into account, support dynamic changes without centralized control, prevent loops, and so on. 5. Interaction between LUF and LRF The LUF, when queried for resolution of a URI, will respond in one of three cases: SSP Domain provided is returned unchanged, with the username portion either the same or different - This indicates that the LUF determined the terminating SSP is the same one identified in the query, potentially with number portability resolution data (an npdi parameter, with or without a routing number). SSP Domain returned is different from the domain provided, with the username portion either the same or different - This indicates that the LUF did find a different terminating SSP domain for the provided address, potentially with number portability resolution data (an npdi parameter, with or without a routing number). This domain translation can occur for a number of reasons including number portability or use of public user identity. An error/not-found type of response - This is where the LUF is unable to validate the domain portion of the provided address, or is not able did not find any domain translation data for the provided address because none exists or the LUF is unable to reach or access it. Schumacher Expires May 3, 2009 [Page 4] Look Up Function vs. Location Routing Function discussion Nov 2008 6. Reasons for separating LUF and LRF logical roles The SF addressing is not provided by an LUF for the following reasons: 1. SF addressing is not static - they change due to dynamic, temporary topology changes, or operator control. 2. SF address availability/reachability is not global - some SF addresses are only reachable for specific neighbor SSPs, or even specific neighbor SSP Signaling Border Elements (SBEs). For example an SBE in Philadelphia might have a receive/listen address X for neighbor SSP SBE's in Philadelphia, but have address Y for others. 3. SF addresses overlap - some SSP's use RFC-1918 addresses for SBE peering connections, and overlap them with others. 4. SF addresses are private - many SSPs do not wish to publish the SBE addresses they use for all peering connections with all peers; they only provide specific addresses to specific peers that need them. The transit SSP information may or may not be available to the LUF, for the following reasons: 1. Transit SSP connections are not static - they change due to dynamic, temporary topology changes, overload conditions, or operator control. 2. Transit SSP connections are not globally routable - some SSP peering connections only service direct bi-lateral traffic, while others are usable for transit traffic but only for specific regions or national codes. 3. Transit SSP connection details are private - many SSPs do not wish to publish the specific connection points, or number of connections, they have with other SSPs. Note that it is entirely possible for the LUF and LRF functions to reside in the same entity, and even for a single resolution query to provide both answers at the same time, converged into a single response; just as it is possible for the LUF and LRF functions to be implemented in the same entity as the SF itself. Schumacher Expires May 3, 2009 [Page 5] Look Up Function vs. Location Routing Function discussion Nov 2008 The discussion here is about logical separation, to allow the two disparate functions to be implementable separately or together, as appropriate. Furthermore, the LUF function is in many ways far simpler than the LRF function, especially for transit path routing cases. For example, it is highly unlikely that a Registry would have topological knowledge for all SSP connections and SBE address relationships for all SSPs. It may have such for a specific group of SSPs, or it may only have LUF type data for resolving the final terminating SSP. For some scenarios, such as direct bi-lateral peering, it may make sense to combine the LUF and LRF functions into the same physical entity in practice, while for other more global scenarios it may not. Regardless, the logical functions are distinct. 7. Security Considerations This document introduces no new security considerations. 8. IANA Considerations This document creates no new requirements on IANA namespaces. 9. Conclusions Conclusion text 10. Acknowledgments Acknowledgment text Schumacher Expires May 3, 2009 [Page 6] Look Up Function vs. Location Routing Function discussion Nov 2008 11. References 11.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 11.2. Informative References [SPEERMINT-Terms] Malas, D., Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint-terminology-16.txt, February 12, 2008 [SPEERMINT-Arch] Penno, R., Malas, D., Khan, S., Uzelac, A., Hammer, M., "SPEERMINT Peering Architecture", draft-ietf- speermint-architecture-06.txt, May 2, 2008 Author's Address Greg Schumacher Sprint Nextel 19 Cold Spring Road Holliston, MA, USA 01746 Email: Gregory.schumacher@sprint.com Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA, USA 01803 Email: hkaplan@acmepacket.com 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. Schumacher Expires May 3, 2009 [Page 7] Look Up Function vs. Location Routing Function discussion Nov 2008 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. 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. Schumacher Expires May 3, 2009 [Page 8]