[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6405

     Internet Draft                                                 A.Uzelac
     SPEERMINT                                               Global Crossing
     Intended status: Informational                                  Y.Lee
     Expires: Mar 2007                                               Comcast
                                                                  D.Schwartz
                                                             Kayote Networks
                                                                     E. Katz
                                                                    Xconnect
                                                                     O.Lendl
                                                                     enum.at
                                                                      R.Mahy
                                                                 Plantronics
                                                           November 30, 2007
     
     
                             VoIP SIP Peering Use Cases
               draft-ietf-speermint-voip-consolidated-usecases-04.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 Jan 30, 2008.
     
     Copyright Notice
     
        Copyright (C) The IETF Trust (2007)
     
     
     
     
     
     
     Uzelac (et al)           Expires Mar 30, 2008                  [Page 1]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     Abstract
     
        This document will capture VoIP use case for SIP Peering.  It is a
        consolidation of Speermint use cases drafts. This document depicts
        many common VoIP peering use cases. These use cases are categorized
        into three types: Direct, Indirect and Assisted. They are not the
        exhaust set of use cases but the most common use cases deployed in
        production today. This document captures them to provide a reference.
     
     
     Table of Contents
     
     
        1. Introduction...................................................3
        2. Terminology....................................................3
        3. Contexts of Use Cases..........................................5
           3.1. Direct Peering............................................5
           3.2. Indirect Peering..........................................6
           3.3. Assisted Peering..........................................6
        4. Functions in the Use Cases.....................................6
           4.1. Look-Up Function..........................................6
           4.2. Location Function.........................................6
           4.3. Signaling Function........................................6
           4.4. Media Function............................................7
        5. Use Cases......................................................7
           5.1. Static Peering Use Cases..................................7
           5.1.1. Static Direct Use Case..................................7
           5.1.1.1. Assisted SSP for Static Direct Use Case...............8
           5.1.1.2. Administrative characteristics........................9
           5.1.1.3. Options and Nuances...................................9
           5.1.2. Static Indirect Use Case................................9
           5.1.2.1. Assisted SSP for Static Indirect Use Case............11
           5.1.2.2. Administrative characteristics.......................11
           5.1.2.3. Options and Nuances..................................11
           5.2. On-demand Peering Use Cases..............................13
           5.2.1. On-demand Direct Use Case..............................13
           5.2.1.1. Assisted SSP for On-demand Indirect Use Case.........13
           5.2.1.2. Administrative characteristics.......................13
           5.2.1.3. Options and Nuances..................................13
           5.2.2. On-demand Indirect Use Case............................13
           5.2.2.1. Assisted SSP for On-demand Indirect Use Case.........14
           5.2.2.2. Administrative Characteristics.......................14
           5.2.2.3. Options and Nuances..................................14
        6. Federations...................................................14
           6.1. Federation Considerations................................14
           6.2. Federation Examples......................................16
           6.2.1. Trivial Federations....................................16
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 2]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
           6.2.2. Access List based......................................16
           6.2.3. TLS based Federations..................................17
           6.2.4. Central SIP Proxy......................................17
           6.2.4.1. Architecture, scalability and business scalability...17
           6.2.5. Private Layer 3 Network................................18
           6.2.6. Peer to Peer SIP.......................................18
           6.2.7. DUNDi..................................................18
        7. Security Considerations.......................................19
        8. IANA Considerations...........................................19
        References.......................................................20
           Normative References..........................................20
           Informative References........................................21
           Author's Addresses............................................21
           Full Copyright Statement......................................22
           Intellectual Property.........................................22
           Acknowledgment................................................22
     
     1. Introduction
     
        This document attempts to capture VoIP use cases for Session
        Initiation Protocol (SIP)[1] based peering.  These use cases will
        assist in identifying requirements and future works for VoIP Peering
        using SIP.
     
        Only use cases related to VoIP are considered in this document.
        Other real-time SIP communications use cases, like Instant Messaging
        (IM) and presence are out of scope for this document.  In describing
        use cases, the intent is descriptive, not prescriptive.
     
        There are existing documents [2][3][4][5][6] that have captured use
        case scenarios.  This draft draws from those documents.  The document
        contains three categories of use cases; Direct, Indirect and
        Assisted.  The use cases contained in this document attempts to be as
        comprehensive as possible, but should not be considered the exclusive
        set of user cases.
     
     2. Terminology
     
        Many terms in this document are referenced to the Speermint
        terminology draft [15]. We also use few additional terms to describe
        the VoIP use cases. We define them in this section.
     
     
     
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 3]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
        o Location Server (LS): A server called upon by originating SSP,
           either Local or Remote, to obtain the Session Establish Data
           (SED). Often, the input to the server is an E.164 number and the
           SED is a SIP URI. The originating SSP's client may call the
           Location Function using ENUM Query/Response, SIP Invite/Redirect,
           or other method depending on originating SSP's infrastructure and
           methods available for the data being interrogated, with the
           response format being appropriate to the Query format. In the
           case of an ENUM Query, the response should be a NAPTR record
           containing the sip URI that can be resolved by the client. In the
           case of a SIP Invite/Redirect, the response should be a SIP
           Redirect (30X) message containing the URI.
     
        o Session Manager (SM): A SM is the home registrar of the user
           endpoint. SM is responsible to receive and send SIP messages from
           the peer. If the user endpoint speaks non-SIP, SM will translate
           the non-SIP protocol to SIP protocol and vice versa.
     
        o Session Border Element (SBE) : A SBE performs signaling sanitation
           and security tasks in the signaling plane of Session
           establishment. Common threats may be DOS or intentionally
           malformed packet/headers.  This device may perform NAT/PAT or
           enable far-end NAT traversal.
     
        o Data Border Element (DBE) : The DBE performs similar functions as
           the SBE, but in the media or data plane.
     
        o User Endpoint (UE): User Endpoint is the client that makes or
           receives calls. UE can be sip based or non-sip based. For non-sip
           based UE, SM acts as a signaling gateway and translates the non-
           sip signaling to sip signaling before sending to SBE.
     
        In this document, we use “O” to indicate “Originating”, “T” to
        indicate “Terminating”, “t” to indicate “Transit”, and “A” to
        indicate “Assisted”. For example, O-SBE is the acronym of Originating
        SBE.
     
     
     
     
     
     
     
     
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 4]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
        +-------------+-------------------------------------+------------+
        |              \        Assisting SSP Domain       /             |
        |               \                                 /              |
        |                \       +------+ +------+       /               |
        |                 \      + a-LS + + a-SM |      /                |
        |                  \     +------+ +-----++     /                 |
        |                   \    +------+ +------+    /                  |
        |           +------+ \   | a-SBE| | a-DBE|   /+------+           |
        |     +-----+ O-LS +  \  +------+ +------+  / + T-LS +-----+     |
        |     |     +------+   \                   /  +------+     |     |
        |     |                 \                 /                |     |
        |     |                  \               /                 |     |
        |     |     +------+      \             /     +------+     |     |
        |     |     | O-SBE+       \           /      + T-SBE|     |     |
        |     |     +---+--+        \         /       +------+     |     |
        |     |         |            \       /                     |     |
        |     |         |             \     /                      |     |
        |     |     +---+--+           \   /          +------+     |     |
        |     +-----+ O-SM |            \ /           | T-SM +-----+     |
        |           +-----++             +            ++-----+           |
        |  +----+         |              |             |         +----+  |
        |  |O-UE+---------+              |             +---------+T-UE|  |
        |  +----+         +------+       |      +------+         +----+  |
        |                 | O-DBE|       |      | T-DBE|                 |
        |                 +------+       |      +------+                 |
        |     Originating SSP Domain     |       Terminating SSP Domain  |
        +----------------------------------------------------------------+
        Figure 1 Generalized Overview
        PLEASE NOTE: In figure one – the elements defined are optional in
        many use cases.
     
     
     
     3. Contexts of Use Cases
     
        Use cases are sorted into 3 general groupings: Direct, Indirect and
        Assisted. Though there may be some overlap among the use cases in
        these categories, there are different requirements between the
        scenarios and this document serves to help identify the requirements
        for SIP Peering for VoIP.  The following definitions are taken from
        the Speermint Terminology draft[15].
     
     3.1. Direct Peering
     
        Direct peering describes those cases in which two service providers
        interconnect without using an intervening layer 5 network.
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 5]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     3.2. Indirect Peering
     
        Indirect, or transit, peering refers to the establishment of either a
        signaling and media path or signaling path alone via one (or more)
        referral or transit network(s). In this case it is generally required
        that a trust relationship is established between the originating
        service provider and the transit network on one side, and the transit
        network and the termination network on the other side.
     
     
     3.3. Assisted Peering
     
        In this case, some entity (usually a 3rd party or federation)
        provides peering assistance to either the originating or terminating
        SIP Service Provider (SSP) by providing one or more functions
        assisting in the routing of SIP requests and the establishment of SIP
        dialogs and sessions between peers.  The assisting entity may provide
        information relating to direct or indirect peering as necessary.
     
     
     4. Functions in the Use Cases
     
        Each use case will follow functions as defined in the Speermint
        Terminology draft [15].
     
     4.1. Look-Up Function
     
        The Look-Up Function (LUF) provides a mechanism for querying an
        internal and/or external database, which maintains a list of SIP user
        name and associated peering domains.
     
     4.2. Location Function
     
        The Location Function (LF) develops call routing data (CRD) by
        discovering the Signaling Function (SF) and the SF’s reachable host
        (IP Address and port).
     
     4.3. Signaling Function
     
        The Signaling Function (SF) performs routing of SIP messages, to
        optionally perform termination and re-initiation of a sessions, and
        to assist in the discovery/exchange of parameters to be used ny the
        Media Function
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 6]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     4.4. Media Function
     
        The Media Function (MF) performs media related function suck as
        media, DTMF, etc transcoding and media security implementation
        between two (or more) SSPs.
     
     5. Use Cases
     
        Please note, there are intra-domain message flows within the use
        cases to serve as supporting background information.  Only inter-
        domain communications is germane to Speermint. We divide the use
        cases into two major categories: Static Peering and On-demand
        Peering. Each peering category can sub-divide to Direct and Indirect.
        Besides, O-SSP and T-SSP can decide to use A-SSP for the peering.
     
     5.1. Static Peering Use Cases
     
        Static Peering [15] describes two SSP form the peering relationship
        with pre-association.
     
     5.1.1. Static Direct Use Case
     
        This is the simplest use case. Two SSP negotiate and agree to
        establish a SIP peering relation. The peer connection is statically
        configured and directly connected two SSP. Besides, they exchange
        peer information such as DSCP policies, subscriber SIP-URI and proxy
        location prior to establishing the connection. They only accept
        traffic originating directly from the trusted peer.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 7]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
         +------------------+-------------------+
         |    Orig Domain   |    Term Domain    |
         |     +--------+   |     +--------+    |
         |     |  O-LS  |   |     |  T-LS  |    |
         |     +--------+   |     +--------+    |
         |  (2) /           |                   |
         |   /(3)           |                   |
         |  +-----+         |          +-----+  |
         |  |O-SM |--------(4)---------|T-SM |  |
         |  +-----+         |          +-----+  |
         |      |           |             |     |
         |     (1)          |            (5)    |
         |      |           |             |     |
         |   +----+         |           +----+  |
         |   |O-UE+===(6)=(RTP)=========+T-UE+  |
         |   +----+         |           +----+  |
         +------------------+-------------------+
        Figure 2 Direct Peering
     
     
        The following is a high-level depiction of the use case.
     
          1. O-UE initiates a call via SIP INVITE
     
          2. O-SM queries for next-hop information from a routing database.
             This is the Look-up Function as described in the terminology
             draft.
     
          3. Routing database entity replies with route to called party
     
          4. Call sent to terminating domains session manager.
     
          5. Session manager determines called party status and directs call
             to called party.
     
          6. RTP is established between O-UE and T-UE.
     
     
     
     5.1.1.1. Assisted SSP for Static Direct Use Case
     
        Given the O-SSP policy, the O-SSP may request assistance from A-SSP
        to provide LF and LUF. For example, A-SSP provides ENUM service to O-
        SSP to translate the TEL-URI to S-URI. Since O-SSP and T-SSP have
        direct Layer-5 connectivity, they do not require A-SSP for signaling.
        If O-SSP and T-SSP have their own LF and LUF, they can establish the
        peer relationship without any A-SSP involved.
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 8]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     5.1.1.2. Administrative characteristics
     
        The static direct use case is typically implemented in a scenario
        where exists a strong degree of trust between the 2 administrative
        domains. Both administrative domains normally sign a peer agreement
        which state clearly the peering policies and terms.
     
     5.1.1.3. Options and Nuances
     
        In Figure 2, O-SM and T-SM connect directly. An operator may decide
        to deploy a SBE between its SM and the peer network. Normally, the
        operator will deploy the SBE in the edge of its administrative
        domain. The signaling traffic will pass between two networks through
        the SBE. The operator has many reasons to deploy a SBE. For example,
        the SM may use RFC1918 addresses that are not routable in the peer
        operator network. The SBE can perform NAT function. Also, the SBE
        eases the operation cost for deploying old or removing new SM.
        Consider the deployment architecture where multiple SMs connect to a
        single SBE. An operator can add or remove a SM without coordinating
        with the peer operator. The peer operator sees only the SBE. As long
        as the SBE maintain intact, the peer operator does not need to be
        notified.
     
        When an operator deploys a SBE, the operator is required to advertise
        the SBE to the peer LS so that the peer operator can locate the SBE
        and route the traffic to the SBE accordingly.
     
        SBE deployment is a decision within an administrative domain. Either
        administrative domain or both administrative domains can decide to
        deploy SBE. To the peer network, most important is to identify the
        next-hop address. Whether next-hop is SM or SBE, the peer network
        will not see any difference.
     
     5.1.2. Static Indirect Use Case
     
        Similar to the Static Direct Use Case, O-SSP and T-SSP has pre-
        arranged assignment for the peer relationship. The difference between
        Static Direct Use Case and Static Indirect Use Case is the O-SSP and
        T-SSP do not have direct Layer-5 connectivity. They require one or
        multiple Transit Domains to assist routing the SIP messages.
     
     
     
     
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                  [Page 9]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
                           +------------------+
                           |  Transit Domain  |
                           |                  |
                           |       +------+   |
                           |    +--+ t-SM |   |
                           |   / +-+ t-LS |   |
                           |  / /  +------+   |
        +------------------+ / /              +----------------------+
        |  Orig Domain     |/ /               |      Term Domain     |
        |      +-----------+ /                |         +--------+   |
        |     /            |/                 |         |  T-LS  |   |
        |    /  +----(3)---+                  |         +--------+   |
        |  (2) /           |                  |                      |
        |  /  /            |                  |                      |
        |+-----+     +-----+      +-----+     +-----+         +-----+|
        ||O-SM |-(4)-|O-SBE|------+t-SBE+-(5)-+T-SBE+---(6)---|T-SM ||
        |+-----+     +-----+      +-----+     +-----+         +-----+|
        |    |             |                  |     |            |   |
        |   (1)            |                  |     |           (7)  |
        |    |             |                  |     |            |   |
        | +----+     +-----+      +-----+     +-----+          +----+|
        | |O-UE+=====|0-DBE|=(8)==+t-DBE+=====+T-DBE+==========+T-UE||
        | +----+     +-----+      +-----+     +-----+          +----+|
        +------------------------------------------------------------+
        Figure 3 Indirect via Transit Domain
     
     
          1. O-UE initiates a call.
     
          2. The O-SM performs next-hop determination for the called party.
             This look-up traverses the administrative boundary between the
             originating and the assisting domain.
     
          3. The result of the query will be the assisting domains’s SBE (t-
             SBE) that is interconnected to the transit domain via the O-SBE.
     
          4. O-SM signals the t-SBE via the O-SBE.
     
          5. t-SBE routes call to T-SBE within terminating domain.
     
          6. T-SBE signals T-SM.
     
          7. T-SM signals the called party, T-UE.
     
          8. RTP is established between UEs via DBE path typically
             coordinated by the Transit Domain.
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 10]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     
     5.1.2.1. Assisted SSP for Static Indirect Use Case
     
        Similar to the Static Direct Use Case, O-SSP can use an A-SSP to
        provide LUF and LF. In addition, O-SSP must use an A-SSP for SF  to
        act as the transit domain to route SIP messages to T-SSP. Note that
        O-SSP can use multiple A-SSP for LUF, LF and SF. There is no
        requirement to have one A-SSP to provide all the functions
     
     5.1.2.2. Administrative characteristics
     
        The Static Indirect Use Case is normally implemented in cases where
        no direct interconnection exists between originating and terminating
        domains due to either business or physical constraints.
     
        Orig Domain .--. Transit = Relationship O-T
     
        In the O-T relationship, typical policies, features or functions that
        deem this relationship necessary are NP, Ubiquity of termination
        options, and masquerading of originating VoIP network gear.
     
        Term Domain .--. Transit = Relationship T-T
     
        In the T-T relationship, typical policies, features or functions
        observed consist of codec “scrubbing”, anonimizing, and transcoding.
     
     5.1.2.3. Options and Nuances
     
        In Figure 3, the A-SSP serves only the O-SSP and T-SSP. It is
        possible that A-SSP serves as the hub for multiple SSPs. Each SSP is
        the spoke to the A-SSP which does not need to have direct connections
        among other SSPs. To originate a call to a remote number, the SSP
        will send the SIP request to the A-SSP. A-SSP is the default peer for
        all the numbers that are unknown to the O-SSPs. A-SSP can route the
        call to one of its served SSP or to PSTN if A-SSP can’t locate the
        next-hop for that call in its own LS. The routing logic in the A-SSP
        is hidden to the SSP. Figure 4 shows the high-level network setup.
     
     
     
     
     
     
     
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 11]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
                               +---------+
                               |Assisted |
                               |   SSP   |
                               +--+-+-+--+
                                  | | |
                                  | | |
                                  | | |
                                  | | |
                                  | | |
                                  | | |
                 +----------------+ | +------------------+
                 |                  |                    |
                 |                  |                    |
                 |                  |                    |
                 |                  |                    |
             +---+----+         +---+----+           +---+----+
             |        |         |        |           |        |
             |  SSP1  |         |  SSP2  |  .......  |  SSPx  |
             |        |         |        |           |        |
             +--------+         +--------+           +--------+
        Figure 4 Hub-and-Spoke Assisted SSP
     
        A-SSP facilitates direct session establishment between the O-SSP and
        T-SSP.  There may be elements that provide SIP proxy functionality,
        and are often implemented in practice by SBE(s) and DBE(s) which may
        "filter" or "normalize" and provide network-hiding for incoming
        messages en route to their final destination.  Fear and distrust
        coupled with continued interoperability and security concerns have
        revived the need for the neutral central element role enabled by this
        peering model.
     
        Popularity of this model can be attributed to the concentration of
        functions provided by A-SSP.  As an external element, A-SSP can
        provide the full set of services for SSPs, and through its own
        relationships with the SSP eliminate the need of all SSPs for pair-
        wise service relationships.  A-SSP can potentially encompass a large
        namespace of users that is accessible in one query to external SSP
        members (or not -depending on policy).
     
        In addition there is an interoperability function usually performed
        by an A-SSP SBE, almost guaranteeing interoperability and protocol
        interchangeability between member SSPs.  As part of the
        interoperability there is also is media sub-function enabling the
        federation to enforce a standard set of codecs or alternatively
        provide transcoding functionality to make sure there is media
        interoperability as well. Finally, A-SSP can implement the routing
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 12]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
        function enabling traffic shaping and throttling across the
        federation.
     
     5.2. On-demand Peering Use Cases
     
        On-demand Peering [15] describes two SSP form the peering
        relationship without pre-arranged agreement.
     
     5.2.1. On-demand Direct Use Case
     
        The basis of this use case is built on the fact that there is NOT a
        pre-established relationship between the O-SSP and the T-SSP.  The O-
        SSP and T-SSP did not share any information prior to the dialog
        initiation request. When the O-SM invokes the LUF and LF on the R-
        URI, the terminating user information must be publicly available.
        Besides, when the O-SM routes the request to the T-SM, the T-SM must
        accept the request without any pre-association with O-SSP.
     
     5.2.1.1. Assisted SSP for On-demand Indirect Use Case
     
        Given the O-SSP policy, the O-SM may invoke A-SSP for one or more
        assistances. In On-demand peering, the A-SSP must publicly announce
        what assisted functions it provides and accept any on-demand request.
     
     5.2.1.2. Administrative characteristics
     
        The On-demand Direct Use Case is typically implemented in a scenario
        where the T-SSP allows any O-SSP to reach its serving subscribers. T-
        SSP administrative domain does not require any pre-arranged agreement
        to accept the call. T-SSP makes its subscribers information available
        in public. This model mimics the email model. Sender does not need an
        agreement to send email to the receiver.
     
     5.2.1.3. Options and Nuances
     
        Similar to Static Direct Use Case. O-SSP and T-SSP can decide to
        deploy SBE. T-SSP is open to the public, T-SSP should prepare to
        suffer from the spam problem existing in email system. VoIP spamming
        is considered more annoying than email spamming to the subscribers.
        T-SSP must apply rules to filter spammed calls.
     
     5.2.2. On-demand Indirect Use Case
     
        The difference between Direct and Indirect Use Case is the O-SSP
        invokes an A-SSP to forward requests to T-SSP blindly, regardless of
        LUF or LF. This use case is also referring to a “transit” model of
        SIP peering.  Similar to the On-demand Direct Use Case model, the A-
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 13]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
        SSP must publicly announce that it accepts request and is capable to
        route the request to the T-SSP.
     
     5.2.2.1. Assisted SSP for On-demand Indirect Use Case
     
        Given the O-SSP policy, the O-SM may invoke a A-SSP similar to the
        procedures described in the Direct On-demand Use Case.
     
     5.2.2.2. Administrative Characteristics
     
        The On-demand In-direct Use Case describes a scenario where T-SSP
        accepts any call from O-SSP and O-SSP does not have direct Layer-5
        connectivity to the T-SSP. O-SSP will rely on its A-SSP to forward
        the SIP request to the T-SSP. This use case is useful for enterprises
        where they rely on the trusted A-SSP to handle incoming and outgoing
        requests.
     
     5.2.2.3. Options and Nuances
     
        T-SSP shares the same problems of which On-demand Indirect Use Case
        suffers. T-SSP should apply filter rules for VoIP spam.
     
     6. Federations
     
          This section discusses the federation concept, explains which
          technical parameters make up the foundation of a federation and
          provides examples.
     
          Contrary to the previous section, this section does not focus on
          specific implementation details like the presence of SBCs or other
          border elements. The aim here is to provide a broader view on what
          kinds of arrangements are possible.
     
          The concrete implementation details (e.g. "direct with one SBC"
          versus "direct with two SBCs") can involve all the use cases thus
          far described in the document.
     
     
     6.1. Federation Considerations
     
          Each federation has to specify how a few core operations which are
          to be performed by its members.
     
          These include:
     
          1. Peer Discovery
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 14]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
          This specifies how a SSPs discovers that he can place a specify
          call to a peering partner in this federation.
     
          Possible solution are e.g.: a manually configured list of TN-
          prefixes and domain names, automatically obtained list of reachable
          prefixes/domains by some sort if intra-federation route
          announcements, trial queries to the federation's LS, trial lookups
          in federation-internal databases (e.g. private DNS),public database
          lookups (e.g. I-ENUM).
     
          2. Location Server
     
          What methods are used for TN to URI mapping?
     
          Examples: Public User-ENUM, public Infrastructure ENUM, private
          ENUM tree, SIP Redirect, DUNDi.
     
          3. Next Hop Domain Resolution
     
          If the LS did not return an URI of the form sip:user@IP-address,
          then the originating SSP has to translate the domain part of the
          URI to an IP-address (plus perhaps fall-backs) in order to contact
          the next hop.
     
          Examples: RFC3263 in the public DNS. RFC3263 in a federation
          private DNS. RFC3263 in the public DNS with split-DNS, P2P SIP,
          modified RFC3263 in the public DNS (e.g. a federation-specific
          prefix to the domain name).
     
          4. Call Setup
     
          The federation may also define specifics on what SIP features need
          to be used when contacting the next hop in order to a) reach the
          next hop at all and b) to prove that the sender is a legitimate
          peering partner.
     
          Examples: hard-code transport (TCP/UDP/TLS), non-standard port
          number, specific source IP address (e.g. in a private L3 network),
          which TLS client certificate to use, other authentication scheme.
     
          5. Filtering Incoming Calls
     
          On the receiving side, the border element needs to determine
          whether the INVITE it just received really came from a member   of
          the federation. This is the flip side of 4.
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 15]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
          Example: verify TLS cert, check incoming interface/VLAN,check
          source IP address against a configured list of valid ones.
     
     6.2. Federation Examples
     
          This section lists some examples of how federations can operate.
     
     6.2.1. Trivial Federations
     
          A private peering arrangement between two SSPs is a special case of
          a federation. These two SSP have agreed to exchange calls amongst
          themselves and they have set up whatever SBC/LS/SBE plus Layer
          3infrastructure they need to route and complete the calls.
     
          It is thus not needed to treat bi-lateral peerings as conceptually
          different to federation-based peering.
     
          On the other extreme, the set of all SSPs implementing an open SIP
          service according to RFCs 3261/3263/3761 also fulfills the
          definition of a federation.  In that case, the technical rules are
          contained in these three RFCs, the LS is the public DNS. Whether
          some of these SSPs use SBCs as border elements is not relevant.
     
          The administrative model of this federation is the "email model":
          There is no "member list", any SIP server operating on the Internet
          which implements call routing according to these RFCs is implicitly
          a member of that federation. No business relationship is needed
          between "members", thus no money is likely to change hands for
          terminating calls. There is no contractual protection against
          nuisance calls, SPIT, or denial of service attacks.
     
     6.2.2. Access List based
     
          If running an open SIP proxy is not desired, then a group of SSPs
          which want to allow calls from each other can collect the list of
          IP addresses of all their border elements.
     
          This list is redistributed to all members which use it to configure
          firewalls in front of their ingress elements.  Thus calls from
          other members of this federation are accepted while calls from
          other hosts on the Internet are blocked.
     
          Whether SSPs deploy SBCs as border elements is not relevant.  Call
          routing can still be done via standard RFC rules.
     
          Whenever a new member joins this club every other SSP needs to
          adapt its filter rules.
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 16]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     
     6.2.3. TLS based Federations
     
          Another option to restrict incoming calls to federation members is
          to use Transport Layer Security (TLS) certificates as access
          control. This works best if the federation runs a certificate
          authority (CA) which signs the TLS keys of each member SSP.  Thus
          the ingress element of a SSP needs to check only whether the client
          certificate presented by the calling SIP proxy contains a proper
          signature from that CA.
     
          Adding support for Certificate Revocation Lists solves the issue of
          blocking calls from former members of that federation.  The main
          benefit of this model is that no changes need to be made at the
          ingress element of all old members whenever a SSP joins that
          federation.
     
     6.2.4. Central SIP Proxy
     
          One way to simplify the management of these firewall rules is to
          route all SIP messages via a central proxy.
     
          In that case, all federation members just need to open up their
          ingress elements to requests from that central server. A new SSP
          just triggers a change in the configuration of this box and not at
          all other SSPs.
     
          While centralized solutions may entail typical hub-and-spoke
          architecture considerations, the added overall federation
          scalability with respect to the number of interconnects required,
          their associated policies and management make this approach quite
          popular today.
     
          This is an example of Assisted Peering.
     
     
     6.2.4.1. Architecture, scalability and business scalability
     
          The network architecture which in the case centralized model would
          reflect a hub and spoke model - should be weighed against a
          distributed model. While such a centralized model presents well-
          known network and server scalability challenges, a distributed
          model requires higher interconnection complexity, reflected in
          provisioning and the need for the maintenance of such
          relationships.
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 17]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     6.2.5. Private Layer 3 Network
     
          Federations can also establish a separate layer 3 network for their
          peering traffic. This could be implemented e.g. by creating a new
          VLAN at an Internet exchange point to which all members of that
          federation connect their SBEs.
     
          Alternatively, a federation can establish a smaller version of the
          Internet to which only members are allowed to connect.  The GRX
          network of the mobile operators is an example of a dedicated layer
          3 infrastructure.
     
          Such a private layer 3 network can also be implemented using
          virtual private network (VPN) technologies like IPsec.
     
          In all these cases the SBE can assume that any SIP requests it
          receives via an interfaces located in this L3 network comes from
          legitimate peering partner.
     
          The separation of the peering network from the Internet makes it
          easier to protect the peering arrangement from attacks and to
          ensure QoS.
     
     6.2.6. Peer to Peer SIP
     
          P2PSIP replaces the RFC3263 rules by a lookup in a distributed hash
          table (DHT). A federation could use this technology to implement
          call routing between the peers: the border elements of all members
          participate in the DHT algorithm and distribute routing information
          this way.
     
          Only members of the federation thus can use information stored in
          the DHT which could be the basis of both call routing within the
          federation as well as access control between members.
     
     6.2.7. DUNDi
     
          Distributed Universal Number Discovery (DUNDi)
          [http://www.dundi.com/dundi.txt] can also be used to build
          federations: DUNDi itself acts as a distributed LS which can add
          dynamically generated passwords to the URIs it returns.
     
          This way, the T-SBE can verify that an incoming calls comes from a
          member of this DUNDi cloud.
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 18]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     7. Security Considerations
     
          This document introduces no new security considerations.  However,
          it is important to note that session interconnect, as described in
          this document, has a wide variety of security issues that should be
          considered in documents addressing both protocol and use case
          analyzes.
     
     8. IANA Considerations
     
          This document creates no new requirements on IANA namespaces
          [RFC2434].
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 19]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     References
     
     Normative References
     
        [1]   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.
     
        [2]   Schwartz, David, draft-schwartz-speermint-use-cases-federations
     
        [3]   Mahy, Rohan, draft-mahy-speermint-direct-peering
     
        [4]   Lendl, Otmar, draft-lendl-speermint-federations
     
        [5]   Lee, Yiu, draft-lee-speermint-use-case-cable
     
        [6]   Uzelac, Adam, draft-uzelac-speermint-use-cases
     
        [7]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
              (SIP): Locating SIP Servers", RFC 3263, June 2002.
     
        [8]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
              T. Wright, "Transport Layer Security (TLS) Extensions", RFC
              3546, June 2003.
     
        [9]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
              "RTP: A Transport Protocol for Real-Time Applications", STD 64,
              RFC 3550, July 2003.
     
        [10]  Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
              numbers with the Session Initiation Protocol (SIP)", RFC 3824,
              June 2004.
     
        [11]  Peterson, J., “Address Resolution for Instant Messaging and
              Presence”,RFC 3861, August 2004.
     
        [12]  Peterson, J., "Telephone Number Mapping (ENUM) Service
              Registration for Presence Services", RFC 3953, January 2005.
     
        [13]  ETSI TS 102 333: " Telecommunications and Internet converged
              Services and Protocols for Advanced Networking (TISPAN); Gate
              control protocol".
     
        [14]  Peterson, J., "enumservice registration for Session Initiation
              Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 20]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     Informative References
     
        [15]  Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint-
              terminology-06 (work in progress), 2006.
     
        [16]  Mule, J-F., “SPEERMINT Requirements for SIP-based VoIP
              Interconnection”, draft-ietf-speermint-requirements-00.txt,
              June 2006.
     
        [17]  Camarillo, G. “Requirements from SIP (Session Initiation
              Protocol) Session Border Control Deployments“, draft-camarillo-
              sipping-sbc-funcs-04.txt, June, 2006.
     
        [18]  Habler, M., et al., “A Federation based VOIP Peering
              Architecture”, draft-lendl-speermint-federations-03.txt,
              September 2006.
     
     Author's Addresses
     
     
        Adam Uzelac
        Global Crossing
        Email: adam.uzelac@globalcrossing.com
     
        Rohan Mahy
        Plantronics
        Email: rohan@ekabal.com
     
        Yiu L. Lee
        Comcast Cable Communications
        Email: yiu_lee@cable.comcast.com
     
        David Schwartz
        Kayote Networks
        Email: david.schwartz@kayote.com
     
        Eli Katz
        Xconnect Global Networks
        Email: ekatz@xconnect.net
     
        Otmar Lendl
        enum.at GmbH
        Email: otmar.lendl@enum.at
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 21]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     Full Copyright Statement
     
          Copyright (C) The IETF Trust (2007).
     
          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.
     
     
     Intellectual Property
     
          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.
     
     Acknowledgment
     
          Funding for the RFC Editor function is provided by the IETF
          Administrative Support Activity (IASA).
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 22]
     

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Mar 2008
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Uzelac (et al.)          Expires Mar 30, 2008                 [Page 23]
     

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/