[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: Standards Track                                 Y.Lee
     Expires: Dec 2007                                               Comcast
                                                             Kayote Networks
                                                                     E. Katz
                                                                June 8, 2007
                             VoIP SIP Peering Use Cases
     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
        The list of Internet-Draft Shadow Directories can be accessed at
        This Internet-Draft will expire on Dec 8, 2007.
     Copyright Notice
        Copyright (C) The IETF Trust (2007)
     Uzelac (et al)           Expires Dec 8, 2007                   [Page 1]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
        This document will capture VoIP use case for SIP Peering.  It is a
        consolidation of Speermint use cases drafts.
     Table of Contents
        1. Introduction...................................................3
        2. Terminology....................................................3
        3. Use Cases......................................................6
           3.1. Direct Use Cases..........................................7
           3.1.1. Minimalist Direct.......................................7
  Administrative characteristics........................8
           3.1.2. Direct with one SBE.....................................8
  Options and Nuances...................................9
  Administrative characteristics........................9
           3.1.3. Direct with two SBEs....................................9
  Options and Nuances..................................10
  Administrative characteristics.......................11
           3.2. Indirect.................................................11
           3.2.1. Transit PSP............................................11
  Administrative Characteristics.......................12
           3.3. Assisted.................................................13
           3.3.1. Assisted PSP...........................................13
        4. Federations...................................................14
           4.1. Federation Considerations................................15
           4.2. Federation Examples......................................16
           4.2.1. Trivial Federations....................................16
           4.2.2. Access List based......................................17
           4.2.3. TLS based Federations..................................17
           4.2.4. Central SIP Proxy......................................17
  Architecture, scalability and business scalability...18
           4.2.5. Private Layer 3 Network................................18
           4.2.6. Peer to Peer SIP.......................................18
           4.2.7. DUNDi..................................................19
        5. Security Considerations.......................................19
        6. IANA Considerations...........................................19
           Normative References..........................................20
           Informative References........................................21
           Author's Addresses............................................21
           Full Copyright Statement......................................22
           Intellectual Property.........................................22
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 2]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
     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 for VoIP Peering using SIP and
        provide a perspective on future specifications.
        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 complete.
     2. Terminology
        The terminology for this draft will draw from the Speermint
        terminology draft. [15]
        o Direct Peering: Direct peering describes those cases in which two
           service providers interconnect without using an intervening layer
           5 network.  This peering model can also be considered a bi-
           lateral relationship historically.
        o Indirect Peering: Indirect, or Transit peering refers to the
           establishment of a secure signaling and bearer path via one (or
           more) referral or transit network(s).
        o Assisted Peering: In this case, some entity employs a central SIP
           proxy (which is not itself a VSP) to facilitate direct calls
           between participating networks.
        o Federations: A federation is a group of SPs which agree to receive
           calls from each other. A Federation may use a Peering Service
           Provider, (in any modes Direct, Indirect, Assisted) to facilitate
           some or all of the Assisted Peering services.
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 3]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
        o Voice Service Provider (VSP): A Voice Service Provider (or VSP) is
           an entity that provides transport of SIP signaling to its
           customers.  In the event that the VSP is also an SP, it may also
           provide media streams to its customers.  Such a service provider
           may additionally be interconnected with other service providers;
           that is, it may "peer" with other service providers.  A VSP may
           also interconnect with the PSTN.
        o Originating VSP (O-VSP): A VSP where the calling party resides.
           The O-VSP is in the Originating Domain, and/or defines the
           Originating Domain.
        o Terminating VSP (T-VSP): A VSP of the called party. The T-VSP is
           in the Terminating Domain, and/or defines the Originating Domain.
        o Peering Service Provider (PSP): A logical entity providing peering
        o Direct PSP (D-PSP): PSP providing location function or service
           enabling direct peering relationship.
        o Assisting PSP (A-PSP): An Assisting VSP is some entity that
           employs a central SIP proxy (which is not itself a VSP) to bridge
           calls between participating networks.
        o Signaling Border Element (SBE): A signaling border element (SBE)
           [15] provides signaling-related functions.  A SBE is frequently
           deployed on a domain's border as a B2BUA.
        o Originating SBE (O-SBE): SBE in originating domain.
        o Terminating SBE (T-SBE): SBE in terminating domain.
        o Transit SBE (t-SBE): SBE in the transit domain.
        o Assisted SBE (A-SBE): SBE in Assisted domain.
        o Data Path Border Element: A data path border element (DBE) [15]
           provides media-related functions such as deep packet inspection
           and modification, media relay, and firewall support under SBE
           control.  As was the case with the SBE, a DBE is frequently
           deployed on a domain's border.
        o Originating DBE (O-DBE): The DBE connects to the terminating DBE.
        o Terminating DBE (T-DBE): The DBE connects to the originating DBE.
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 4]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
        o Transit DBE (t-DBE): The DBE that is located in the transit
           domain. This is NOT to be confused with the T-DBE of the
           terminating domain.
        o Location Server (LS): A server called upon by O-VSP, either Local
           or Remote, to translate an E.164 number into a SIP URI. The O-
           VSP's client may call the Location Function using ENUM
           Query/Response, SIP Invite/Redirect, or other method depending on
           O-VSP'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 entity responsible for sending
           and receiving the SIP messages from or to Signaling Path Border
           Element (SBE). It is also responsible for locating the user home
           proxy. SM is logical, it MAY contain one functional entity or
           multiple functional entities.
        o Originating SM (O-SM): The SM originates the call. In this
           context, it is Alice's SM.
        o Terminating SM (T-SM): The SM terminates the call. In this
           context, it is Bob's SM.
        o Transit SM (t-SM): The SM of the transit domain.
        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.
        o Originating UE (O-UE): Alice's UE.
        o Terminating UE (T-UE): Bob's UE.
        o Federations:  A federation is a group of VSPs which agree to
           receive calls from each other using pre-agreed technical and
           administrative procedures.
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 5]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
        |              \          Transit Domain           /             |
        |               \                                 /              |
        |                \       +------+ +------+       /               |
        |                 \      + t-LS + + t-SM |      /                |
        |                  \     +------+ +-----++     /                 |
        |                   \    +------+ +------+    /                  |
        |           +------+ \   | t-SBE| | t-DBE|   /+------+           |
        |     +-----+ O-LS +  \  +------+ +------+  / + T-LS +-----+     |
        |     |     +------+   \                   /  +------+     |     |
        |     |                 \                 /                |     |
        |     |                  \               /                 |     |
        |     |     +------+      \             /     +------+     |     |
        |     |     | O-SBE+       \           /      + T-SBE|     |     |
        |     |     +---+--+        \         /       +------+     |     |
        |     |         |            \       /                     |     |
        |     |         |             \     /                      |     |
        |     |     +---+--+           \   /          +------+     |     |
        |     +-----+ O-SM |            \ /           | T-SM +-----+     |
        |           +-----++             +            ++-----+           |
        |  +----+         |              |             |         +----+  |
        |  |O-UE+---------+              |             +---------+T-UE|  |
        |  +----+         +------+       |      +------+         +----+  |
        |                 | O-DBE|       |      | T-DBE|                 |
        |                 +------+       |      +------+                 |
        |     Originating Domain         |        Terminating Domain     |
        Figure 1 Generalized Overview
        PLEASE NOTE: In figure one – the elements defined are optional in
        many use cases.
     3. 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.
        Per information in the Speermint terminology draft, the direct use
        cases involve those cases in which two service providers interconnect
        without using an intervening layer 5 network.  This approach is also
        considered a bi-lateral peering agreement.
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 6]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
        Indirect or transit peering involves a third party proxying both
        signaling and bearer between the Originating and Terminating Domains.
        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, so there is no requirement for a trust relationship
        directly between the originating and terminating.
        Assisted use cases involve the use of a third party for signaling.
        This third party may or may not have a pre-existing relationship with
        the O-VSP, and/or T-VSP. The A-VSP may only provide next-hop
        discovery for the O-VSP on behalf of the T-VSP and proxy all
        communications, or may be more intimately involved by maintaining
        session state in the signaling plane. Other functions which may be
        provided in Assisted Peering include, peering policies, and
        administrative rules for such sessions (settlement, abuse-handling,
        security requirements) and the specific rules for the technical
        details of the interconnection (signaling, media, layers 1-4 etc.)
     3.1. Direct Use Cases
        There are intra-domain message flows within the use cases to serve as
        supporting background information.  Only inter-domain communications
        is germane to Speermint.
     3.1.1. Minimalist Direct
          1. O-UE initiates a call via SIP INVITE
          2. O-SM queries for next-hop information from a routing database.
          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.
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 7]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
         |    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 Minimalist Direct
  Administrative characteristics
        The minimalist direct use case is typically implemented in a scenario
        where exists a strong degree of trust between the 2 administrative
        domains.  Neither the Originating nor Terminating domains have a
        dedicated network element (i.e. Session Border Element - SBE) that
        serves any domain demarcation purpose.  This can and should be
        considered an “Open” peering model.
     3.1.2. Direct with one SBE
        In this type of interconnection scenario, the SBE is owned and
        operated within the originating administrative domain for purposes of
        domain demarcation, security, and trust boundry.
          1. O-UE initiates a call.
          2. The O-SM performs next-hop determination for the called party
             via the O-LS.  This can be done via ENUM/DNS/Redirect 3XX
             multiple choices and/or static routing.
          3. The result of the query will be O-SBE that is logically
             interconnected to the terminating domain.
          4. O-SM will signal O-SBE.
          5. O-SBE routes call to T-SM within terminating domain.
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 8]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
          6. T-SM signals the called party, T-UE.
          7. RTP established between the O-UE and T-UE.
        |    Orig Domain   |    Term Domain    |
        |     +--------+   |     +--------+    |
        |     |  O-LS  |   |     |  T-LS  |    |
        |     +--------+   |     +--------+    |
        |  (2) /           |                   |
        |   /(3)           |                   |
        |+-----+     +-----+          +-----+  |
        ||O-SM |-(4)-|O-SBE+----(5)---|T-SM |  |
        |+-----+     +--+--+          +-----+  |
        |    |             |             |     |
        |   (1)            |            (6)    |
        |    |             |             |     |
        | +----+           |           +----+  |
        | |O-UE+=====(7)=(RTP)=========+T-UE+  |
        | +----+           |           +----+  |
        Figure 3 Direct with one SBEs
  Options and Nuances
        There is evidence that both the signaling and the media would
        traverse a single element, and in this case, there would be an
        element that would be both the SBE and DBE.
  Administrative characteristics
        The direct peering with a single SBE is typically implemented in the
        scenario where the Originating domain is a VoIP Service Provider
        (VSP) and the Terminating domain is an Enterprise IP telephony
        deployment. The SBE(s) provides the VSP with the ability to support
        overlapping RFC1918 address space via NAT, Session limiting, Session
        “scrubbing” to permit only certain SDP options, etc.
     3.1.3. Direct with two SBEs
        Multiple SBCs are implemented in this interconnection scenario.  The
        SBEs are operated within different administrative domains.
          1. O-UE initiates a call.
     Uzelac (et al.)          Expires Dec 8, 2007                   [Page 9]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
          2. The O-SM performs next-hop determination for the called party
             via the O-LS.  This can be done via ENUM/DNS/Redirect 3XX
             multiple choices and/or static routing.
          3. The result of the query will be O-SBE that is interconnected to
             the terminating domain, but administered in the originating
          4. O-SM will signal O-SBE.
          5. O-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 Data Border Edge elements.
         +---------------------+       +-----------------------+
         |    Orig Domain      |       |    Term Domain        |
         |     +--------+      |       |     +--------+        |
         |     |  O-LS  |      |       |     |  T-LS  |        |
         |     +--------+      |       |     +--------+        |
         |  (2) /              |       |                       |
         |   /(3)              |       |                       |
         |+-----+        +-----+       +-----+         +-----+ |
         ||O-SM |---(4)--|O-SBE|--(5)--|T-SBE+---(6)---|T-SM | |
         |+-----+        +-----+       +-----+         +-----+ |
         |    |                |       |                  |    |
         |   (1)               |       |                 (7)   |
         |    |                |       |                  |    |
         | +----+        +-----+       +-----+          +----+ |
         | |O-UE+========+O-DBE+==(8)==+T-DBE+==========+O-UE| |
         | +----+        +-----+       +-----+          +----+ |
         +---------------------+       +-----------------------+
        Figure 4 Direct with two SBEs
  Options and Nuances
        There is evidence that both the signaling and the media would
        traverse a single element, and in this case, there would be an
        element that would be both the SBE and DBE. (note: this is not
        depicted in figure above)  There may also be a single or multiple
        DBEs as depicted in the diagram.
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 10]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
  Administrative characteristics
        The direct peering use case with 2 SBEs is typically seen in where
        both the originating and terminating domain are VSPs.  Both maintain
        that there is perceived value in “protecting” their VSP network cores
        via SBEs/DBEs/etc. This use case is also applicable where one or both
        domains are enterprises.
     3.2. Indirect Use Cases
     3.2.1. Transit PSP
        This call flow is similar to the minimalist approach, but with a
        Peering Service Provider (PSP) providing signaling(i.e. SIP
        “normalizing”) and bearer (i.e. transcoding) services to facilitate
        communications between the originating and terminating domains.  For
        this call flow all signaling and bearer to and from the
        Originating/Terminating domains traverses the Transit Domain,
        possibly for services like Q0S, interoperability and security.
          1. O-UE initiates a call.
          2. The O-SM performs next-hop determination for the called party
             via the LS within the Transit domain.  This can be done via
             ENUM/DNS/Redirect 3XX multiple choices and/or static routing.
          3. The result of the query will be the transit provider’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 Dec 8, 2007                  [Page 11]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
                           |   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 5 Indirect via Transit PSP
  Administrative Characteristics
        The transit peering 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.
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 12]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
     3.3. Assisted Use Cases
        Assisted use cases involve an assisting PSP (A-PSP) that facilitates
        direct session establishment between the O-VSP and T-VSP.  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-PSP.  As an external element, A-PSP can
        provide the full set of services for VSPs, and through its own
        relationships with the VSP, eliminate the need of all VSPs for pair-
        wise service relationships.  A-PSP can potentially encompass a large
        namespace of users that is accessible in one query to external VSP
        members (or not -depending on policy).
        In addition there is an interoperability function usually performed
        by an SBE, almost guaranteeing interoperability and protocol
        interchangeability between member VSPs.  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-PSP can implement the routing
        function enabling traffic shaping and throttling across the
     3.3.1. Assisted PSP
        This is a direct call flow, as in the minimalist approach, but with
        an A-PSP aiding the originating to terminating domain relationship.
        The A-PSP may have a relationship with the originating and/or
        terminating domain.
          1. O-UE initiates a call.
          2. The O-SM performs next-hop determination for the called party
             via the A-LS within the Assisting domain.  This can be done via
             ENUM/DNS/Redirect 3XX multiple choices and/or static routing.
          3. The result of the query will be the T-SBE that is accessible via
             the O-SBE. There must be a common IP denominator between the
             originating and terminating domains. (i.e. Internet)
          4. Signaling will traverse the O-SM onwards to the O-SBE.
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 13]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
          5. O-SBE routes call to T-SBE.
          6. T-SBE signals T-SM.
          7. T-SM signals the called party, T-UE.
          8. Bearer path established between O-UE and T-UE through O/A/T DBE.
                        |     Assist Domain      |
                        |                        |
                        |       +--------+       |
                        |       |  A-LS  |       |
                        |       ++---+---+       |
                        |        |   |           |
        +---------------+        |   |           +-----------------+
        |    Orig Domain \       |   |          /   Term Domain    |
        |      +----------+------+   |         /     +--------+    |
        |     /            \         |        /      |  LS-t  |    |
        |    /  +----(3)----+--------+       /       +--------+    |
        |  (2) /             \              /                      |
        |  /  /               +------------+                       |
        |+-----+        +-----+            +-----+         +-----+ |
        ||O-SM |---(4)--|O-SBE+-----(5)----+T-SBE+---(6)---|T-SM | |
        |+-----+        +-----+            +-----+         +-----+ |
        |    |                |            |                  |    |
        |   (1)               | (common IP |                 (7)   |
        |    |                |denominator)|                  |    |
        | +----+        +-----+            +-----+          +----+ |
        | |O-UE+========+O-DBE+=====(8)====+T-DBE+==========+T-UE| |
        | +----+        +-----+            +-----+          +----+ |
        Figure 6 Direct with Assisted PSP
        PLEASE NOTE – elements depicted are optional.
     4. 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.
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 14]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
          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.
     4.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
          This specifies how a VSPs 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 VSP 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
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 15]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
          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.
          Example: verify TLS cert, check incoming interface/VLAN,check
          source IP address against a configured list of valid ones.
     4.2. Federation Examples
          This section lists some examples of how federations can operate.
     4.2.1. Trivial Federations
          A private peering arrangement between two VSPs is a special case of
          a federation. These two VSP 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 VSPs 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 VSPs 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.
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 16]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
     4.2.2. Access List based
          If running an open SIP proxy is not desired, then a group of VSPs
          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 VSPs 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 VSP needs to
          adapt its filter rules.
     4.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 VSP.  Thus
          the ingress element of a VSP 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 VSP joins that
     4.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 VSP
          just triggers a change in the configuration of this box and not at
          all other VSPs.
          While centralized solutions may entail typical hub-and-spoke
          architecture considerations, the added overall federation
          scalability with respect to the number of interconnects required,
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 17]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
          their associated policies and management make this approach quite
          popular today.
          This is an example of Assisted Peering.
  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
     4.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.
     4.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.
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 18]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
          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.
     4.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.
     5. 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
     6. IANA Considerations
          This document creates no new requirements on IANA namespaces
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 19]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
     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 Dec 8, 2007                  [Page 20]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
     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
        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 Dec 8, 2007                  [Page 21]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
     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
     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-
          Funding for the RFC Editor function is provided by the IETF
          Administrative Support Activity (IASA).
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 22]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases  Dec 2007
     Uzelac (et al.)          Expires Dec 8, 2007                  [Page 23]

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