[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]