SPEERMINT Routing Architecture Message Flows
draft-ietf-speermint-flows-05

Versions: 00 01 02 03 04 05                                             
     Speermint Working Group                                 H. Kaplan (Ed.)
     Internet Draft                                              Acme Packet
     Intended status: Informational                                 R. Penno
     Expires: September 2009                                 Juniper Networks
                                                                    D. Malas
                                                                   CableLabs
                                                                     S. Khan
                                                                     Comcast
                                                                   A. Uzelac
                                                             Global Crossing
                                                               March 9, 2009
     
     
                    SPEERMINT Routing Architecture Message Flows
                            draft-ietf-speermint-flows-05
     
     
     Status of this Memo
     
        This Internet-Draft is submitted to IETF in full conformance with the
        provisions of BCP 78 and 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/ietf/1id-abstracts.txt.
     
        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.
     
        This Internet-Draft will expire on September 9, 2009.
     
     Copyright and License Notice
     
        Copyright (c) 2009 IETF Trust and the persons identified as the
        document authors.  All rights reserved.
     
        This document is subject to BCP 78 and the IETF Trust's Legal
        Provisions Relating to IETF Documents in effect on the date of
        publication of this document (http://trustee.ietf.org/license-info).
        Please review these documents carefully, as they describe your rights
        and restrictions with respect to this document.
     
     Kaplan, et al         Expires September 9, 2009                [Page 1]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     Abstract
     
        This document describes example message flows associated with the
        SPEERMINT routing architecture, relative to various peering
        scenarios.
     
     Table of Contents
     
     
        1. Introduction...................................................3
        2. Definitions....................................................3
        3. Peering Scenarios..............................................4
        4. Legend for Message Flows.......................................6
        5. Basic Peering Message Flow.....................................8
           5.1. Message Examples for Basic Peering Model..................9
        6. On-Demand Peering.............................................11
           6.1. Transport Layer Security.................................11
        7. Static Peering................................................13
           7.1. TLS......................................................13
           7.2. IPsec....................................................14
           7.3. Co-Location..............................................14
        8. Federation Based Peering......................................15
           8.1. Central Federation Proxy.................................15
           8.2. Central ENUM Federation..................................17
        9. Media Relay...................................................19
        10. Peering Message Flow Phases..................................19
           10.1. Discovery Phase.........................................21
           10.2. Security Establishment Phase............................22
           10.3. Signaling Exchange Phase................................22
           10.4. Media Exchange Phase....................................23
        11. Security Considerations......................................23
        12. IANA Considerations..........................................24
        13. Acknowledgments..............................................24
        14. References...................................................24
           14.1. Normative References....................................24
           14.2. Informative References..................................25
        Author's Addresses...............................................25
     
     Conventions used in this document
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC-2119 [1].  The
     
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 2]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        terminology in this document conforms to RFC 2828, "Internet Security
        Glossary".
     
     1. Introduction
     
        This document shows the message flows associated with the most
        relevant SPEERMINT routing architecture peering scenarios. Most of
        the message diagrams were based on previous work described within
        existing IETF standards documents.
     
        The document focuses on the messages exchanged for the purpose of
        Layer 5 peering [7] between two domains.  Messages exchanged for the
        purpose of setting up SIP sessions within a domain are considered out
        of scope and are already defined in other IETF documents.
     
     2. Definitions
     
        SSP: SIP Service Provider, the administrative entity providing SIP
             services utilizing SIP.  Note that an SSP may be a traditional
             Service Provider, an Enterprise, or any administrative domain
             context.
     
        LUF: Look-Up Function, the functional step(s) necessary to determine
             for a given SIP request, which terminating domain it should be
             sent to.
     
        LRF: Location Routing Function, the functional step(s) necessary to
             determine for a given SIP request's terminating domain, the path
             to follow to reach the terminating domain.
     
        Routing: In the context of this document, it is forwarding of an out-
             of-dialog SIP request.
     
        SED: Session Establishment Data, the LUF and LRF data needed and used
             to route a SIP request to the next-hop(s) associated with
             reaching the terminating domain.
     
        SBE: Signaling-path Border Element, the logical SIP node that
             represents the logical boundaries between SSP domains (a.k.a.,
             the signaling portion of an SBC, I-BCF, etc.).
     
        SF:  Signaling Function, the logical functional role for processing
             SIP requests for peering/routing; i.e., the SBE's role.
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 3]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     
        DBE: Data-path Border Element, the logical node that relays media
             between the logical boundaries of SSP domains (a.k.a., the media
             portion of an SBC, I-BGF, etc.).
     
        MF:  Media Function, the logical functional role for processing media
             for peering purposes, including relaying media; i.e., the DBE's
             role.
     
     
     3. Peering Scenarios
     
        This draft separates the Layer 5 peering scenarios into two major
        peering scenarios:
     
        o  On-demand: In this scenario the SIP proxies in domains A and B
           establish a peering relationship driven by the necessity to
           deliver a SIP message to another domain, without a pre-existing
           relationship.  This is sometimes referred as the "email" model.
     
        o  Static: In this scenario the peering relationship between proxies
           A and B is statically pre-provisioned independent of the
           establishment of any SIP session between users in different
           domains.
     
        Media for a given SIP session may follow a different path from
        signaling, only following the IP routed transport path when crossing
        peering domains.  Alternatively, media for a given session can be
        directed to traverse the same SIP device used for Layer 5 peering,
        i.e., the same device that handles signaling when crossing domains.
        This produces three different models:
     
        o  Media-direct: In this model SIP proxies perform Layer 5 peering
           Signaling Function (SF), while media is sent directly between the
           User Agent's (UA's) involved in the session, as shown in Figure 1.
           Therefore signaling and media follow different paths.
     
        o  Integrated: In this model, the device that performs Layer 5 SIP
           peering SF/SBE also processes the associated media when crossing
           domains, as an MF/DBE, as shown in Figure 2.  This function is
           usually referred to as media relay and is usually performed by a
           B2BUA or SBC (Session Border Controller).  See [6] for a complete
           discussion of such SBC functions.  We will refer to this picture
           throughout this document.
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 4]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        o  Decomposed: In this model, media is relayed by a DBE/MF which is
           physically separated from the SBE/SF.  A control protocol,
           typically H.248 or MGCP, is used by the SBE to control the DBE.
           From the UA and peering domain's perspective, the decomposed SBE
           and DBE do not function any differently than an integrated SBC.
           For the purposes of this document, one can consider this model as
           just a specific variant of the integrated model, and is not
           discussed separately.
     
     
     
        ............................          ..............................
        .                          .          .                            .
        .                +-------+ .          . +-------+                  .
        .                |       | .          . |       |                  .
        .                |  DNS  | .          . | DNS   |                  .
        .                |   1   | .          . |  2    |                  .
        .                |       | .          . |       |                  .
        .                +-------+ .          . +-------+                  .
        .                    |     .          .     |                      .
        .                    |     .          .     |                      .
        .                +-------+ .          . +-------+                  .
        .                |  SF   | .          . |  SF   |                  .
        .                | Proxy |--------------| Proxy |                  .
        .                |   1   | .          . |  2    |                  .
        .                |       | .          . |       |                  .
        .              / +-------+ .          . +-------+ \                .
        .             /            .          .            \               .
        .            /             .          .             \              .
        .           /              .          .              \             .
        .          /               .          .               \            .
        .         /                .          .                \           .
        .        /                 .          .                 \          .
        .       /                  .          .                  \         .
        .   +-------+              .          .                +-------+   .
        .   |       |              .          .                |       |   .
        .   |       |              .   Media  .                |       |   .
        .   | UA 1  |<========================================>| UA 2  |   .
        .   |       |              .          .                |       |   .
        .   +-------+              .          .                +-------+   .
        .              Domain A    .          .   Domain B                 .
        ............................          ..............................
     
     
                   Figure 1: Basic Peering Picture (media-direct)
     
     
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 5]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        The integrated model is shown below:
     
     
        ............................          ..............................
        .                          .          .                            .
        .                +-------+ .          . +-------+                  .
        .                |       | .          . |       |                  .
        .                |  DNS  | .          . | DNS   |                  .
        .                |   1   | .          . |  2    |                  .
        .                |       | .          . |       |                  .
        .                +-------+ .          . +-------+                  .
        .                    |     .          .     |                      .
        .                    |     .          .     |                      .
        .                +-------+ .          . +-------+                  .
        .                | SBE/SF| .          . | SBE/SF|                  .
        .                |   &   |--------------|   &   |                  .
        .                | DBE/MF|**************| DBE/MF|\                 .
        .               /|       | .          . |       | \                .
        .              / +-------+ .          . +-------+* \ signaling     .
        .             / *          .          .           * \              .
        .            / *           .          .            * \             .
        .           / *            .          .             * \            .
        .          / * media       .          .              * \           .
        .         / *              .          .               * \          .
        .        / *               .          .                * \         .
        .       / *                .          .                 * \        .
        .   +-------+              .          .                +-------+   .
        .   |       |              .          .                |       |   .
        .   |       |              .          .                |       |   .
        .   | UA 1  |              .          .                | UA 2  |   .
        .   |       |              .          .                |       |   .
        .   +-------+              .          .                +-------+   .
        .              Domain A    .          .   Domain B                 .
        ............................          ..............................
     
                        Figure 2: Integrated Peering Picture
     
        In a decomposed model, the Signaling Function (SF) of an SBE, and the
        Media Function (MF) of a DBE, are implemented in separate physical
        entities.  A B2BUA is generally on the SIP path performing the SF.  A
        vertical control protocol between the SF and MF is out of the scope
        of this document.
     
     4. Legend for Message Flows
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 6]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        Dashed lines (---) represent signaling messages that are mandatory to
        the call scenario. These messages can be SIP or DNS protocols.  The
        arrow indicates the direction of message flow.
     
        The Actors:
     
     Element              URI                           IP Address
     -------              ---                           ----------
     User Agent           +12125551212@sp1.example.com   192.0.10.10
     User Agent           +17815551212@sp2.example.net   192.0.20.20
     SBE/Peer-Proxy/SF-1  sbe1.sp1.example.com          192.0.10.111
     SBE/Peer-Proxy/SF-2  sbe2.sp2.example.net          192.0.20.222
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 7]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     5. Basic Peering Message Flow
     
        This section depicts the "basic" Peering message flow.  This does not
        imply this is the most common peering scenario - just a baseline.
        The various scenarios differ mostly of how and when peering is
        implemented. As stated earlier, peering can be establish dynamically
        following the arrival of a message at a border proxy, or statically
        based on an agreement between both domains.
     
             Alice     SF-1        DNS      SF-2         Bob
                |        |          |         |           |
                | INVITE |          |         |           |
                |------->|          |         |           |
                |  100   |          |         |           |
                |<-------|          |         |           |
                |        | NAPTR    |         |           |
                |        | Query    |         |           |
                |        |--------->|         |           |
                |        | NAPTR    |         |           |
                |        | Reply    |         |           |
                |        |"SIP+D2U" |         |           |
                |        |<---------|         |           |
                |        | SRV      |         |           |
                |        | Query    |         |           |
                |        |--------->|         |           |
                |        | SRV      |         |           |
                |        | Reply    |         |           |
                |        |<---------|         |           |
                |        |                    |           |
                |        |       Peering      |           |
                |        |        Phase       |           |
                |        |     [On-Demand]    |           |
                |        |<------------------>|           |
                |        |  INVITE            |           |
                |        |------------------->| INVITE    |
                |        |        100         |---------->|
                |        |<-------------------|           |
                |        |                    | 180       |
                |        |        180         |<----------|
                | 180    |<-------------------|           |
                |<-------|                    | 200       |
                |        |        200         |<----------|
                | 200    |<-------------------|           |
                |<-------|                    |           |
                | ACK    |                    |           |
                |------->| ACK                |           |
                |        |------------------->| ACK       |
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 8]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
                |        |                    |---------->|
                |           Both Way RTP Media            |
                |<=======================================>|
     
     
                |        |                    | BYE       |
                |        | BYE                |<----------|
                | BYE    |<-------------------|           |
                |<-------|                    |           |
                | 200    |                    |           |
                |------->| 200                |           |
                |        |------------------->| 200       |
                |        |                    |---------->|
                |        |                    |           |
     
     
        In the integrated model, media would follow the path shown below. All
        other signaling call flows remain the same.  In the decomposed model,
        the media would also go to a MF/DBE functional entity, but it would
        just be physically separate from the SF/SBE.
     
             Alice   SF/MF-1       DNS      SF/MF-2      Bob
                |        |          |         |           |
                |        |          |         |           |
                |           Both Way RTP Media            |
                |<======>|<==================>|<=========>|
                |        |                    |           |
     
     
     5.1. Message Examples for Basic Peering Model
     
        Message Details
     
     
        F1 INVITE Alice -> SF-1
     
        INVITE sip:+17815551213@sp2.example.net SIP/2.0
        Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43
        Route: <sip:sbe1.sp1.example.com;lr>
        Max-Forwards: 70
        To: <sip:+17815551213@sp2.example.net>
        From: +12125551212 <sip:12125551212@sp1.example.com>;tag=9fxced76sl
        Call-ID: 3848276298220188511
        CSeq: 1 INVITE
        Contact: <sip:alice12345@192.0.10.10:6000>
        Content-Type: application/sdp
        Content-Length: [sum of MIME body length]
     
     
     Kaplan, et al         Expires September 9, 2009                [Page 9]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     
        v=0
        o=- 2890844526 2890844526 IN IP4 192.0.10.10
        s=-
        c=IN IP4 192.0.10.10
        t=0 0
        m=audio 49172 RTP/AVP 0
        a=rtpmap:0 PCMU/8000
     
     
        F2 DNS NAPTR Reply DNS -> SF-1
     
        IN NAPTR 50 50 "s" "SIP+D2U" "" _sip._udp.sp1.example.com.
     
     
        F3 DNS SRV Reply DNS -> SF-1
     
        IN SRV  0        1      5060   sbe2.sp2.example.net
     
     
        F4 INVITE SF-1 -> SF-2
     
        INVITE sip:+17815551213@sp2.example.net SIP/2.0
        Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK87298
        Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43
        Route: <sip:sbe2.sp2.example.net;lr>
        Max-Forwards: 69
        To: <sip:+17815551213@sp2.example.net>
        From: 12125551212 <sip:12125551212@sp1.example.com>;tag=9fxced76sl
        Call-ID: 3848276298220188511
        CSeq: 1 INVITE
        Contact: <sip:alice12345@192.0.10.10:6000>
        Content-Type: application/sdp
        Content-Length: [sum of MIME body length]
     
        v=0
        o=- 2890844526 2890844526 IN IP4 192.0.10.10
        s=-
        c=IN IP4 192.0.10.10
        t=0 0
        m=audio 49172 RTP/AVP 0
        a=rtpmap:0 PCMU/8000
     
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 10]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     6. On-Demand Peering
     
        In the on-demand peering scenario, the relationship between proxies
        in domains A and B is driven by the arrival of a SIP message at proxy
        A directed to a user in domain B (or vice-versa).
     
     6.1. Transport Layer Security
     
        In case this is in fact the first SIP request between two SSPs in an
        on-demand peering relationship, then the SIP request will trigger the
        establishment of the TLS connection.  Otherwise it is assumed the TLS
        connection has been established by some other means and may be
        reused.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 11]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
             Alice   Proxy 1       DNS      Proxy 2      Bob
                |        |          |         |           |
                |        |          |         |           |
                | INVITE |          |         |           |
                |------->|          |         |           |
                | 100    |          |         |           |
                |<-------|          |         |           |
                |        | NAPTR    |         |           |
                |        | Query    |         |           |
                |        |--------->|         |           |
                |        | NAPTR    |         |           |
                |        | Reply    |         |           |
                |        |"SIPS+D2T"|         |           |
                |        |<---------|         |           |
                |        | SRV      |         |           |
                |        | Query    |         |           |
                |        |--------->|         |           |
                |        | SRV      |         |           |
                |        | Reply    |         |           |
                |        |<---------|         |           |
                |        |          |         |           |
                |        |       Peering      |           |
                |        |  [TLS Connection]  |           |
                |        |<------------------>|           |
                |        |                    |           |
                |        |  INVITE            |           |
                |        |------------------->| INVITE    |
                |        |  100               |---------->|
                |        |<-------------------|           |
                |        |                    | 180       |
                |        | 180                |<----------|
                | 180    |<-------------------|           |
                |<-------|                    | 200       |
                |        | 200                |<----------|
                | 200    |<-------------------|           |
                |<-------|                    |           |
                | ACK    |                    |           |
                |------->| ACK                |           |
                |        |------------------->| ACK       |
                |        |                    |---------->|
                |           Both Way RTP Media            |
                |<=======================================>|
                |        |                    | BYE       |
                |        | BYE                |<----------|
                | BYE    |<-------------------|           |
                |<-------|                    |           |
                | 200    |                    |           |
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 12]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
                |------->| 200                |           |
                |        |------------------->| 200       |
                |        |                    |---------->|
                |        |                    |           |
     
        [TBD: add TLS connection for upstream requests?]
     
        F1 INVITE request is the same as for previous direct peering flow.
     
     
        F2 DNS NAPTR Reply DNS -> SF-1
     
        IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.sp1.example.com.
     
     
        F3 DNS SRV Reply DNS -> SF-1
     
        IN SRV  0        1      5061   sbe2.sp2.example.net
     
     
        F4 INVITE SF-1 -> SF-2
     
        INVITE sip:+17815551213@sp2.example.net SIP/2.0
        Via: SIP/2.0/TLS 192.0.10.111:12345;branch=z9hG4bK98479
        Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43
        Route: <sip:sbe2.sp2.example.net;lr>
        Max-Forwards: 69
        To: <sip:+17815551213@sp2.example.net>
        From: 12125551212 <sip:12125551212@sp1.example.com>;tag=9fxced76sl
        Call-ID: 3848276298220188511
        CSeq: 1 INVITE
        Contact: <sip:12125551212@192.0.10.10:6000>
        Content-Type: application/sdp
        Content-Length: ... [SDP omitted from example]
     
     
     7. Static Peering
     
        In the static peering scenario the relationship between proxies A and
        B is not driven by a SIP request, but before-hand through manual
        provisioning.
     
     7.1. TLS
     
        In this model a TLS connection between proxies A and B is provisioned
        following an agreement between the two domains.  Creation of the TLS
        connection may be established through previous SIP message exchanges,
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 13]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        or by continuous message exchange such as OPTIONS requests/responses.
        If Mutual-TLS is used, reverse-path requests may use the same
        connection as defined in [13], or separate TLS connections may be
        used for each request direction.
     
     7.2. IPsec
     
        In this model an IPSec connection between proxies A and B is
        provisioned following an agreement between the two domains.
        Typically either transport-mode ESP is used for SIP signaling only,
        or tunnel-mode is used for either just signaling, or both signaling
        and media.  If tunneling is used, media-relay must be performed as
        described later.  No diagram is shown for the IPsec case, since the
        changes are only at the network layer.
     
     7.3. Co-Location
     
        In this scenario the two proxies are co-located in a physically
        secure location and/or are members of a segregated network, such as a
        VPN. In this case messages between Proxy 1 and Proxy 2 would be sent
        as clear text.
     
             Alice   Proxy 1       DNS      Proxy 2      Bob
                |        |          |         |           |
                |        |                    |           |
                |        |      [Peering]     |           |
                |        |     Co-Location    |           |
                |        |<------------------>|           |
                |        |          |         |           |
                \        /          \         /           \
                /        \          /         \           /
                |        |          |         |           |
                | INVITE |          |         |           |
                |------->|          |         |           |
                | 100    |          |         |           |
                |<-------|          |         |           |
                \        /          \         /           \
                /        \          /         \           /
                |        | BYE                |<----------|
                | BYE    |<-------------------|           |
                |<-------|                    |           |
                | 200    |                    |           |
     
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 14]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     8. Federation Based Peering
     
        Multiple SSP's may be members of the same Federation, such that their
        policies and relationships are defined to be the same for a given
        federation.  Federations are one way for a source and destination
        network to find a common set of procedures for peering.
     
     8.1. Central Federation Proxy
     
        Federation rules can dictate that calls are to be routed via a
        federation-maintained central SIP proxy. In that case no further
        NAPTR/SRV/A lookups need be made.  Instead, the INVITE will be sent
        directly via a preconfigured connection to that proxy.  This proxy
        acts as a redirect proxy, returning SIP 3xx responses with the
        Contact URI(s) identifying the next target(s), which may need
        subsequent DNS resolution per RFC 3263 to resolve.  The SIP Redirect
        proxy essentially performs the role of the LUF and potentially the
        LRF, using SIP as the query protocol.
     
        The following message flow provides an example describing this
        process:
     
             Peer Proxy 1   Federation Proxy   Peer Proxy 2        Bob
                 |                |                |                |
                 |   INVITE       |                |                |
                 |--------------->|                |                |
                 |     302        |                |                |
                 |<---------------|                |                |
                 |     ACK        |                |                |
                 |--------------->|                |                |
                 |     INVITE                      |                |
                 |-------------------------------->|    INVITE      |
                 |             100                 |--------------->|
                 |<--------------------------------|   180          |
                 |             180                 |<---------------|
                 |<--------------------------------|                |
                 |                                 |    200         |
                 |             200                 |<---------------|
                 |<--------------------------------|                |
                 |             ACK                 |                |
                 |-------------------------------->|     ACK        |
                 |                                 |--------------->|
                 |                Both Way RTP Media                |
                 |<================================================>|
                 |                                 |     BYE        |
                 |             BYE                 |<---------------|
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 15]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
                 |<--------------------------------|                |
                 |             200                 |                |
                 |-------------------------------->|     200        |
                 |                                 |--------------->|
     
     
        F1 INVITE Peer Proxy 1 -> Federation Redirect Server
     
        INVITE sip:+17815551213@fed.example.org SIP/2.0
        Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK98479
        Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43
        Max-Forwards: 69
        To: <sip:+17815551213@sp1.example.com>
        From: 12125551212 <sip:12125551212@sp1.example.com>;tag=9fxced76sl
        Call-ID: 3848276298220188511
        CSeq: 1 INVITE
        Contact: <sip:alice12345@192.0.10.10:6000>
        Content-Type: application/sdp
        Content-Length: ... [SDP omitted from example]
     
     
        F2 Redirect response Federation Proxy -> Peer Proxy 1
     
        SIP/2.0 302 Moved Temporarily
        Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK98479
        Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43
        Contact: <sip:+17815551213@sbe2.sp2.example.net>
        To: <sip:+17815551213@sp1.example.com>
        From: 12125551212 <sip:12125551212@sp1.example.com>;tag=9fxced76sl
        Call-ID: 3848276298220188511
        CSeq: 1 INVITE
        Content-Length: 0
     
     
        F3 INVITE Peer Proxy 1 -> Peer Proxy 2
     
        INVITE sip:+17815551213@sbe2.sp2.example.net SIP/2.0
        Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK141344
        Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43
        Max-Forwards: 69
        To: <sip:+17815551213@sp1.example.com>
        From: 12125551212 <sip:12125551212@sp1.example.com>;tag=9fxced76sl
        Call-ID: 3848276298220188511
        CSeq: 1 INVITE
        Contact: <sip:alice12345@192.0.10.10:6000>
        Content-Type: application/sdp
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 16]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        Content-Length: ... [SDP omitted from example]
     
     
     8.2. Central ENUM Federation
     
        Another form of centralized Federation is to use an ENUM
        infrastructure instead of SIP Redirect Proxy, and thus DNS as the
        query protocol for the LUF, and possibly LRF.  The originating SSP
        performs a NAPTR query to a pre-arranged ENUM server (a private DNS
        server deployed for this role), for the destination calling party
        E.164 number, with a private domain root for the Federation.
     
        If the ENUM server provides just an LUF function, it will provide SED
        data identifying the terminating SSP domain, and any number
        portability data required, in its NAPTR response; but then relies on
        the originating SSP to either know how to reach the terminating
        domain or to perform some means of performing the LRF.  If the ENUM
        serve provides both, it will resolve not only the number portability
        information, if any, but also return the next-hop URI target(s) for
        the originating SSP to send the SIP request to.
     
        The following diagram shows a scenario whereby the originating SSP
        performs an LUF query using ENUM-DNS to a central Federation ENUM
        server, which responds with the resolved peer SSP's domain.  In this
        particular case the originating SSP can reach the terminating SSP
        directly, and happens to perform just a DNS request to resolve the
        connection information for the Peer, to reach the Peer's SF-2 SBE.
        This is only one particular scenario - many others are possible.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 17]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
             Alice     SF-1     ENUM   DNS  SF-2         Bob
                |        |      LUF|    |     |           |
                | INVITE |         |    |     |           |
                |------->|         |    |     |           |
                |  100   |         |    |     |           |
                |<-------|         |    |     |           |
                |        | NAPTR   |    |     |           |
                |        | Query   |    |     |           |
                |        |-------->|    |     |           |
                |        | NAPTR   |    |     |           |
                |        | Reply   |    |     |           |
                |        |"E2U+sip"|    |     |           |
                |        |<--------|    |     |           |
                |        | SRV          |     |           |
                |        | Query        |     |           |
                |        |------------->|     |           |
                |        | SRV          |     |           |
                |        | Reply        |     |           |
                |        |<-------------|     |           |
                |        |                    |           |
                |        |       Peering      |           |
                |        |        Phase       |           |
                |        |     [On-Demand]    |           |
                |        |<------------------>|           |
                |        |  INVITE            |           |
                |        |------------------->| INVITE    |
                |        |        100         |---------->|
                |        |<-------------------|           |
                |        |                    | 180       |
                |        |        180         |<----------|
                | 180    |<-------------------|           |
                |<-------|                    | 200       |
                |        |        200         |<----------|
                | 200    |<-------------------|           |
                |<-------|                    |           |
                | ACK    |                    |           |
                |------->| ACK                |           |
                |        |------------------->| ACK       |
                |        |                    |---------->|
                |           Both Way RTP Media            |
                |<=======================================>|
     
     
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 18]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        F1 INVITE Alice -> SF-1
     
        INVITE sip:+17815551213@sp2.example.net SIP/2.0
        Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43
        Route: <sip:sbe1.sp1.example.com;lr>
        Max-Forwards: 70
        To: <sip:+17815551213@sp1.example.com>
        From: +12125551212 <sip:10005551212@sp1.example.com>;tag=9fxced76sl
        Call-ID: 3848276298220188511
        CSeq: 1 INVITE
        Contact: <sip:alice12345@192.0.10.10:6000>
        Content-Type: application/sdp
        Content-Length: ... [SDP omitted from example]
     
     
        F2 DNS ENUM (LUF) query for +17815551213
     
        NAPTR query for "3.1.2.1.5.5.5.1.8.7.1.e164.sp1.example.com"
     
     
        F3 NAPTR Reply
     
        IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1@sbe2.sp2.example.net" _.
     
        [The rest of the examples follow the previous sections]
     
     
     9. Media Relay
     
        In the event that a source and/or destination SSP are part of a
        private network, or peer through a private network, the SSP peers
        must enable the SIP signaling and media to route between the peers.
        This process is implemented by an SBE and DBE, either in an
        integrated or decomposed model.  The core of the process is media
        relaying, whereby the SBE forces the relay of media through its DBE
        by modifying the SDP.
     
     
     10. Peering Message Flow Phases
     
        The message flow phases are Discovery, Security Establishment,
        Signaling Exchange, and Media Exchange.  The following flow provides
        an overview of the phases.  Each of the phases is described
        individually in the following subsections.  For the following
        diagram, the signaling and media exchange phase descriptions have
        been omitted for clarity purposes, because their functionality has
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 19]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        not changed for the purposes of peering.  However, they have been
        explained further in the following subsections.
     
     
               Alice      Peer Proxy          DNS   Peer Policy/Proxy     Bob
                 |            |                |            |              |
                 |INVITE      |                |            |              |
                 |----------->|                |            |              |
                 |         100|                |            |              |
                 |<-----------|                |            |              |
                              |NAPTR Query     |            |              |
                        +---->|--------------->|            |              |
                        |     |     NAPTR Reply|            |              |
        Discovery Phase |     |<---------------|            |              |
        ----------------|     |SRV Query       |            |              |
                        |     |--------------->|            |              |
                        |     |       SRV Reply|            |              |
                        +---->|<---------------|            |              |
                              |                |            |              |
        Security Exch.        |        [TLS Connection]     |              |
        --------------------->|<--------------------------->|              |
           Phase              | INVITE                      |              |
                              |---------------------------->|INVITE        |
                |             |                  100 Trying |------------->|
                |             |<----------------------------|   180 Ringing|
                |             |                 180 Ringing |<-------------|
                |  180 Ringing|<----------------------------|       200OK  |
                |<------------|                      200OK  |<-------------|
                |       200OK |<----------------------------|              |
                |<------------|                             |              |
                | ACK         |                             |              |
                |------------>| ACK                         |              |
                |             |---------------------------->|ACK           |
                |             |                             |------------->|
                |             |      Both Way RTP Media     |              |
                |<========================================================>|
                |             |                             |          BYE |
                |             |                        BYE  |<-------------|
                |         BYE |<----------------------------|              |
                |<------------|                             |              |
                | 200OK       |                             |              |
                |------------>| 200OK                       |              |
                |             |---------------------------->|200OK         |
                |             |                             |------------->|
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 20]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     10.1. Discovery Phase
     
        The first phase of static or dynamic peering requests is discovery.
        The discovery process can be summarized by querying the Location
        Routing Function (LRF) to determine the next phase in the message
        flow.  The discovery phase can take place via a local or external
        federation location function.  Examples of the function may be
        comprised of an ENUM/DNS or redirect server.  After the discovery
        phase has completed, the peering process will progress to a
        subsequent phase, usually the policy or authentication phase.  The
        following message flows provide examples of the discovery phase.
     
        Discovery phase utilizing an ENUM/DNS server as a location function:
     
                       Alice      Peer Proxy          DNS          Peer Proxy
                         |            |                |               |
                         |INVITE      |                |               |
                         |----------->|                |               |
                         |         100|                |               |
                         |<-----------|                |               |
                                      |NAPTR Query     |               |
                                +---->|--------------->|               |
                                |     |     NAPTR Reply|               |
                Discovery Phase |     |<---------------|               |
               -----------------|     |SRV Query       |               |
                                |     |--------------->|               |
                                |     |       SRV Reply|               |
                                +---->|<---------------|               |
                                      |INVITE                          |
                                      |------------------------------->|
     
        Discovery phase utilizing a REDIRECT server as a location function:
     
                           Peer Proxy    Federation Proxy   Peer Proxy
                               |                |               |
                               |   INVITE       |               |
                         +---->|--------------->|               |
         Discovery Phase |     |     302        |               |
        -----------------|     |<---------------|               |
                         |     |     ACK        |               |
                         +---->|--------------->|               |
                               |     INVITE                     |
                               |------------------------------->|
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 21]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
     10.2. Security Establishment Phase
     
        The security establishment phase follows the described methods in
        previous sections of this document.  This phase follows standard
        methods described in [2], so the following flow provides an example
        of this phase, but does not incorporate all possibilities.  This
        phase assumes the previous phases were successfully completed or
        purposefully omitted per peering implementation.
     
                           Peer Proxy                       Peer Proxy
                               |                                |
                               | INVITE                         |
                         +---->|------------------------------->|
                         |     |        [TLS Connection]        |
          Security Exch. |     |<------------------------------>|
         ----------------|     |               401 Unauthorized |
              Phase      |     |<-------------------------------|
                         |     | INVITE                         |
                         +---->|------------------------------->|
                               |                     100 Trying |
                               |<-------------------------------|
                               |                    180 Ringing |
                               |<-------------------------------|
     
     10.3. Signaling Exchange Phase
     
        The signaling exchange phase is a necessary step to progress towards
        establishing peering.  This phase may incorporate the security
        exchange phase, but it is not required.  This phase follows standard
        methods described in [2], so the following flow provides an example
        of this phase, but does not incorporate all possibilities.
     
                           Peer Proxy                       Peer Proxy
                               |                                |
                               |        [TLS Connection]        |
                         +---->|<------------------------------>|
                         |     | INVITE                         |
                         |     |------------------------------->|
         Signaling Exch. |     |                     100 Trying |
        -----------------|     |<-------------------------------|
              Phase      |     |                    180 Ringing |
                         |     |<-------------------------------|
                         |     |                         200 OK |
                         |     |<-------------------------------|
                         |     | ACK                            |
                         |     |------------------------------->|
                         |     |                            BYE |
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 22]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
                         |     |<-------------------------------|
                         |     | 200 OK                         |
                         +---->|------------------------------->|
                               |                                |
     
     
     10.4. Media Exchange Phase
     
        The media exchange phase is negotiated and established during the
        signaling exchange phase.  This phase follows standard methods
        described in [2], so the following flow provides an example of this
        phase, but does not incorporate all possibilities.
     
                           Alice      Peer Proxy          Peer Proxy      Bob
                       +---->|INVITE      |                   |            |
                       |     |----------->| INVITE            |            |
                       |     |        100 |------------------>| INVITE     |
                       |     |<-----------|        100 Trying |----------->|
          Media Exch.  |     |            |<------------------|        100 |
        ---------------|     |            |                   |<-----------|
           Phase       |     |            |                   |        180 |
                       |     |            |       180 Ringing |<-----------|
                       |     |        180 |<------------------|        200 |
                       |     |<-----------|            200 OK |<-----------|
                       |     |        200 |<------------------|            |
                       |     |<-----------|                   |            |
                       |     |ACK         |                   |            |
                       +---->|----------->|ACK                |            |
                             |            |------------------>|ACK         |
                             |            |                   |----------->|
                             |             Both Way RTP Media |            |
                             |<===========================================>|
                             |            |                   |            |
                             |            |                   |        BYE |
                             |            |               BYE |<-----------|
                             |         BYE|<------------------|            |
                             |<-----------|                   |            |
                             |200         |                   |            |
                             |----------->|200                |            |
                             |            |------------------>|200         |
                             |            |                   |----------->|
     
     11. Security Considerations
     
        The level of security required during the establishment and
        maintenance of a SIP peering relationship between two proxies can
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 23]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        vary greatly. In general all security considerations related to the
        SIP protocol are also applicable in a peering relationship.
     
        If the two proxies communicate over an insecure network, and
        consequently are subject to attacks/eavesdropping/etc., the use of
        TLS or IPSec would be advisable.
     
        If there is physical security and the proxies are co-located, or the
        proxies are situated in a segregated network (such as a VPN), one
        could argue that weaker measures are sufficient.
     
     12. IANA Considerations
     
        N/A
     
     13. Acknowledgments
     
        Thanks to Reinaldo Penno for his work as the original author of this
        document, and to Otmar Lendl for his contributions.
     
     14. References
     
     14.1. Normative References
     
        [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
              Levels", BCP 14, RFC 2119, March 1997.
     
        [2]   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.
     
        [3]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
              (SIP): Locating SIP Servers", RFC 3263, June 2002.
     
        [4]   Srisuresh, P. and K. Egevang, "Traditional IP Network Address
              Translator (Traditional NAT)", RFC 3022, January 2001.
     
        [5]   Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
              Summers, "Session Initiation Protocol (SIP) Basic Call
              Flow Examples", BCP 75, RFC 3665, December 2003.
     
        [6]   ETSI TS 102 333: " Telecommunications and Internet converged
              Services and Protocols for Advanced Networking (TISPAN); Gate
              control protocol".
     
        [7]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
              Notification", RFC 3265, June 2002.
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 24]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        [8]   Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.
     
        [9]   Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and
              E. Lear, "Address Allocation for Private Internets", RFC 1918,
              February 1996.
     
     14.2. Informative References
     
        [10]  Meyer, D., Malas, D., "SPEERMINT Terminology", Internet Draft,
              draft-ietf-speermint-terminology-16, February 2008.
     
        [11]  Boulton, C., Rosenberg, J., Camarillo, G., "Best Current
              Practices for NAT Traversal for SIP", Internet Draft, draft-
              ietf-sipping-nat-scenarios-08, April 2008.
     
        [12]  Camarillo, G., Penfield, R., Hawrylyshen, A., "Requirements
              from SIP (Session Initiation Protocol) Session Border
              Controller Deployments", Internet Draft, draft-camarillo-
              sipping-sbc-funcs-06, June 2008.
     
        [13]  Gurbani, V., Mahy, R., Tate, B., " Connection Reuse in the
              Session Initiation Protocol (SIP)", draft-ietf-sip-connect-
              reuse-11, July 2008.
     
     Author's Addresses
     
        Hadriel Kaplan
        Acme Packet
        71 Third Ave.
        Burlington, MA 01803, USA
        Email: hkaplan@acmepacket.com
     
        Daryl Malas
        CableLabs
        858 Coal Creek Circle
        Louisville, CO, 80027, USA
        EMail: d.malas@cablelabs.com
     
        Sohel Khan, Ph.D.
        Comcast Cable Communications
        USA
        Email: sohel_khan@cable.comcast.com
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 25]


     Internet-Draft      draft-ietf-speermint-flows-05            March 2009
     
     
        Reinaldo Penno
        Juniper Networks
        1194 N Mathilda Avenue
        Sunnyvale, CA, USA
        Email: rpenno@juniper.net
     
        Adam Uzelac
        Global Crossing
        1120 Pittsford Victor Road
        PITTSFORD, NY 14534, USA
        Email: adam.uzelac@globalcrossing.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kaplan, et al         Expires September 9, 2009               [Page 26]