Internet DRAFT - draft-kaplan-drinks-lrf-requirements
draft-kaplan-drinks-lrf-requirements
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]
