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]