[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Internet Draft                                                 A.Uzelac
SPEERMINT                                               Global Crossing
Expires: March 2007                                    October 16, 2006



                       SIP Peering Use Case for VSPs
                  draft-uzelac-speermint-use-cases-00.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   This document may only be posted in an Internet-Draft.

   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 March 16, 2007.






Uzelac                  Expires March 16, 2007                 [Page 1]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


Abstract

   This document describes the typical interconnection scenarios for SIP
   peering within varying contexts.  In all the scenarios, two or more
   administrative domains have some pre-established agreement that
   permits both signaling and media to traverse the network boundary.

Table of Contents


   1. Introduction...................................................2
   2. Terminology....................................................2
   3. Assumptions....................................................3
   4. Background for Use Cases.......................................3
   5. Use Cases......................................................4
      5.1. Proxy(o) to SBC(o) to Proxy(t)............................4
      5.2. Proxy(o) to SBC(o) to SBC(t) to Proxy(t)..................5
      5.3. Proxy(o) to SBC(T) to SBC(T) to Proxy(t)..................7
      5.4. Proxy(o) to SBC(o) to SBC(T) to SBC(T) to SBC(t) Proxy(t).8
   6. Security Considerations........................................9
   7. IANA Considerations............................................9
   References.......................................................10
      Normative References..........................................10
      Informative References........................................10
   Author's Addresses...............................................12
   Intellectual Property Statement..................................12
   Disclaimer of Validity...........................................12
   Copyright Statement..............................................13
   Acknowledgment...................................................13

1. Introduction

   The intention of this document is to depict the current SIP Peering
   scenarios of the VoIP Service Provider. (VSP) The use cases involve
   VSPs as both a supplier of VoIP directly to end users, and within an
   Inter-Exchange Carrier (IXC) context, meaning providing SIP
   origination and termination services between VSPs.

2. Terminology

   o  VoIP Service Provider (VSP): - This term VoIP Service Provider is
      consistent with SPEERMINT Terminology [12].  The individual types
      of VSPs are defined below.

   o  Originating VSP - VSP(o): A VSP where the calling party resides.

   o  Terminating VSP - VSP(t): A VSP where he called party resides.


Uzelac                  Expires March 16, 2007                 [Page 2]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


   o  Transit VSP - VSP(T): A VSP which is responsible for transiting
      sessions from one VSP to another VSP.  The Transit VSP is
      typically not the registrar for the user. A Transit VSP can also
      be an Access VSP.

   o  Session Border Controller (SBC): A SIP Intermediary device
      implemented as a B2BUA. [17]

3. Assumptions

   o  All call flows are implemented in a collapsed signaling and media
      at the administrative boundary.  The media flows are symmetrical
      across the boundary.

   o  Transcoding, if required, is done at first point of recognized
      media incompatibility.

   o  There is assumed IP reachability between network elements within
      administrative domain, as well as those network session border
      elements that "straddle" boundaries of both administrative
      domains.

   o  There is no assumption of private (RFC1918) or public address
      space being used.

4. Background for Use Cases

   In the VSP interconnection scenarios illustrated in this document,
   the VoIP network border is "ring-fenced" with Session Border
   Controllers. As noted in [17], there are many functions that a SBC
   performs at the border of the VoIP network.

   It is important to understand the trust boundaries of the
   interconnection VSP administrative domains. Figure 1 shows the trust
   boundaries between the different networks that exchange traffic.














Uzelac                  Expires March 16, 2007                 [Page 3]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


                 VSP Core Network Operator's Interconnection

   +---Untrusted Domain--++---Trusted Domain---++---Untrusted Domain--+
       ,-----.                   ,-------.                   ,-----.
     ,'       `.              ,-'         `-.              ,'       `.
    /           \         /-----\          /-----\        /           \
   (    VSP-1    )<------>| SBC |+-------+| MGW  |<----->(    PSTN     )
    \           /         \--+--/ \      / \--+--/        \           /
     `.       ,'         /   |     \    /     |  \         `.       ,'
       '-----'          ;    |      \_ /      |   :          '-----'
                        :    |     /   \      |   ;
       ,-----.           \   |    /     \     |  /           ,-----.
     ,'       `.          \  |   /       \    | /          ,'       `.
    /           \         /--+--+---------+/--+--\        /           \
   (    VSP-2    )<------>| SBC |          | SBC |<----->(    VSP-3    )
    \           /         \-----/          \-----/        \           /
     `.       ,'              '             '              `.       ,'
       '----''                  \----------/                 '----''
   Figure 1 VSP Core Network

   In the following use cases there are subtle, but significant
   differences to the interconnection design.  Administrative domains
   are interconnected by one or more Session Border Controllers (SBC)
   that are Back-to-Back User Agents (B2BUA).  The SBC facilitates,
   among other functions, demarcation between the interconnected
   administrative domains.  This is mostly done between VSPs, but there
   are instances of multiple administrative domains within a single VSP.
   The illustration of the MGW<->PSTN interconnect is noted as out of
   scope for this document, but shown to as it's part of the "untrusted"
   domain.

   NOTE: The SBC performs anonymizing services where all identifying
   information on Alice is removed. The anonymizing service is not
   related to privacy for the calling or called party, rather topology
   hiding and network abstraction. The SBC may also identify the need to
   perform codec media conversion (transcoding), if required to complete
   the call.

5. Use Cases

5.1. Proxy(o) to SBC(o) to Proxy(t)

   In this type of interconnection scenario, the SBC is owned and
   operated within the originating administrative domain.





Uzelac                  Expires March 16, 2007                 [Page 4]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


     1. The proxy of origination performs some next-hop determination
        for the called party.  This can be done via ENUM/DNS/Redirect
        3XX multiple choices and/or static routing.

     2. The result of the query will be a SBC that is directly
        interconnected to the terminating domain.

     3. Proxy will signal the SBC.

     4. The SBC performs some next-hop determination for the called
        party.  This can be done via ENUM/DNS/Redirect 3XX multiple
        choices and/or static routing.

     5. The result of this query is the Proxy server within VSP(t)'s
        network.

     6. SBC signals the proxy.

   +-----Orig Domain--------+---Term Domain--+
        +--------+          |    +--------+
        |ENUM/DNS|          |    |ENUM/DNS|
        | Proxy  |          |    | Proxy  |
        +--------+          |   /+--------+
     (1) /                  | (4)/
      /(2)                  |/ (5)
     +-----+          +-----+ /       +-----+
     |Proxy|---(3)----|SBC  |----(6)--|Proxy|
     +-----+          +-----+         +-----+
         |                  |            |
         |                  |            |
         |                               |
        +--+                            +--+
        |UA|                            |UA|
        +--+                            +--+

   Figure 2 Proxy(o) to SBC(o) to Proxy(t)

5.2. Proxy(o) to SBC(o) to SBC(t) to Proxy(t)

   Multiple SBCs are implemented in this interconnection scenario.  The
   SBCs are operated within different administrative domains.

     1. The proxy within the originating domain performs some next-hop
        determination for the called party.  This can be done via
        ENUM/DNS/Redirect 3XX multiple choices and/or static routing.




Uzelac                  Expires March 16, 2007                 [Page 5]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


     2. The next-hop would be one of possibly many SBCs that are
        interconnected with the VSP(t).

     3. Proxy signals SBC1.

     4. The SBC1 performs some next-hop determination for the called
        party.  This can be done via ENUM/DNS/Redirect 3XX multiple
        choices and/or static routing. In this scenario, SBC1 queries
        within the terminating network's administrative domain.

     5. The result of this query is VSP(t)'s SBC.

     6. SBC1 would them forward the signaling to the appropriate SBC
        within VSP(t), in this case SBC2.

     7. SBC2 performs some next-hop determination for the called party.
        This can be done via ENUM/DNS/Redirect 3XX multiple choices
        and/or static routing.

     8. The result of this query is Proxy in VSP(t).

     9. SBC2 signals Proxy

   +-----Orig Domai  -----++-------Term Domain--- --------+
                          |       _____+--------+
   +--------+             |      /     |ENUM/DNS|
   |ENUM/DNS|             |     /  ----| Proxy  |
   | Proxy  |             |    /  /    +--------+
   +--------+             |  (4) /     | |  |
    (1)  |                |  /  (5)    |(7)(8)
     |  (2)               | /  /       | |  |
    +-----+          +----+/  /        +----+       +-----+
    |Proxy|---(3)--  |SBC |--/         |SBC |--(9 --|Proxy|
    +-----+          |    |-----(6)----|    |       +-----+
        |            +----+            +----+           |
        |                 |            |                |
        |                 |            |                |
        |                 |            |                |
       +--+                                           +--+
       |UA|                                           |UA|
       +--+                                           +--+

   Figure 3 Proxy(o) to SBC(o) to SBC(t) to Proxy(t)






Uzelac                  Expires March 16, 2007                 [Page 6]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


5.3. Proxy(o) to SBC(T) to SBC(T) to Proxy(t)

   In this interconnection scenario, three VSPs are involved in the call
   flow.  There is a VSP of origination referred to as VSP(o).  There is
   also a terminating VSP, referred to as VSP(t).  In this use case,
   VSP(o) does not have a direct interconnection, contractual agreement
   or any way to directly send calls to VSP(t).  In this case a third
   VSP provides transit services.  This VSP is referred to as VSP(T).
   This method of communication is depicted in the figure below.


    +----VSP(o)------+-----VSP(T)-------+---VSP(t)------+
    +--Orig Domain---+--Transit Domain--+--Term Domain--+
                     |                  |        _____+--------+
   +--------+        +--------+         |       /     |ENUM/DNS|
   |ENUM/DNS|        |ENUM/DNS|         |      /  ----| Proxy  |
   | Proxy  |        | Proxy  |         |     /  /    +--------+
   +--------+        +--------+         |   (7) /
    (1)  |           |(4)  |            |   /  (8)
     |  (2)          | |  (5)           |  /  /
    +-----+          +-----+       +----+-/  /
    |Proxy|----(3)---| SBC1|--(6)--|SBC2|---/      +-----+
    +-----+          +-----+       +----+----(9)---|Proxy|
        |            |                  |          +-----+
        |            |                  |              |
        |            |                  |              |
        |                                              |
       +--+                                          +--+
       |UA|                                          |UA|
       +--+                                          +--+
   Figure 4 Proxy - SBC-SBC - Proxy

     1. The proxy within the originating domain performs some next-hop
        determination for the called party. This can be done via
        ENUM/DNS/Redirect 3XX multiple choices and/or static routing.

     2. The next-hop would be one of possibly many SBCs that border with
        VSP(T), but is owned and operated by VSP(o).

     3. The proxy in VSP(o) signals SBC1

     4. SBC1 performs some next-hop determination for the called party.
        This can be done via ENUM/DNS/Redirect 3XX multiple choices
        and/or static routing. This process occurs within VSP(T).

     5. The result of this query would be SBC2 that is also under the
        administrative responsibility of VSP(T).


Uzelac                  Expires March 16, 2007                 [Page 7]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


     6. SBC1 signals SBC2.

     7. Another separate next-hop route determination process will occur
        within VSP(t).

     8. The result is the terminating proxy.

     9. SBC2 signals terminating proxy.

5.4. Proxy(o) to SBC(o) to SBC(T) to SBC(T) to SBC(t) Proxy(t)

   As in the interconnection scenario depicted in section 5.3. , three
   VSPs are involved in the call flow.  The proxy within the originating
   domain performs some next-hop determination for the called party.
   This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or
   static routing.  The next-hop would be one of possibly many SBCs that
   border with VSP(T), but is owned and operated by VSP(o).  The SBC
   performs some next-hop determination for the called party. This can
   be done via ENUM/DNS/Redirect 3XX multiple choices and/or static
   routing.  The result of this query would be the SBC that is under the
   administrative responsibility of VSP(T).  A distinctly separate next-
   hop route determination process will occur within VSP(T) that may
   take into account some originating information, like VSP(o)'s SBC.
   The initial SBC in VSP(T) performs a next-hop determination for the
   called party. This can be done via ENUM/DNS/Redirect 3XX multiple
   choices and/or static routing.  The result would be a second SBC
   within VSP(T) that is interconnected to VSP(o).  This second SBC
   performs some next-hop determination for the called party. This can
   be done via ENUM/DNS/Redirect 3XX multiple choices and/or static
   routing.  The result of this query would be one of possibly many SBCs
   within the administrative responsibility of VSP(t).

   +----VSP(o)-------+-----VSP(T)-------+---VSP(t)------+
   +--Orig Domain----+--Transit Domain--+--Term Domain--+
                     |                  |
    +-----+    +-----+-----+      +-----+-----+   +-----+
    |Proxy|----| SBC | SBC |------| SBC | SBC |---|Proxy|
    +-----+    +-----+-----+      +-----+-----+   +-----+
        |            |                  |             |
        |            |                  |             |
        |            |     +-------+    |             |
        |                  | Proxy |                  |
       +--+                +-------+                 +--+
       |UA|                                          |UA|
       +--+                                          +--+




Uzelac                  Expires March 16, 2007                 [Page 8]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


6. Security Considerations


This document introduces no new security considerations.  However, it
is important to note that session interconnect, as described in this
document, has a wide variety of security issues that should be
considered in documents addressing both protocol and use case
analyzes.


7. IANA Considerations


This document creates no new requirements on IANA namespaces
[RFC2434].

































Uzelac                  Expires March 16, 2007                 [Page 9]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


References

Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Mealling, M. and R. Daniel, "The Naming Authority Pointer
         (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [3]   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.

   [4]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
         (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [5]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
         3546, June 2003.

   [6]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [7]   Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
         numbers with the Session Initiation Protocol (SIP)", RFC 3824,
         June 2004.

   [8]   Peterson, J., "Address Resolution for Instant Messaging and
         Presence",RFC 3861, August 2004.

   [9]   Peterson, J., "Telephone Number Mapping (ENUM) Service
         Registration for Presence Services", RFC 3953, January 2005.

   [10]  ETSI TS 102 333: " Telecommunications and Internet converged
         Services and Protocols for Advanced Networking (TISPAN); Gate
         control protocol".

   [11]  Peterson, J., "enumservice registration for Session Initiation
         Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.

Informative References

   [12]  Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint-
         terminology-06 (work in progress), May 2006.



Uzelac                  Expires March 16, 2007                [Page 10]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


   [13]  Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP
         Interconnection", draft-ietf-speermint-requirements-00.txt,
         June 2006.

   [14]  Mahy, R., "A Minimalist Approach to Direct Peering", draft-
         mahy-speermint-direct-peering-00.txt, June 19, 2006.

   [15]  Penno, R., et al., "SPEERMINT Routing Architecture Message
         Flows", draft-ietf-speermint-flows-00.txt", August 2006.

   [16]  Lee, Y., "Session Peering Use Case for Cable", draft-lee-
         speermint-use-case-cable-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.

   [19]  Mahy, R., "A Telephone Number Mapping (ENUM) Service
         Registration for Instant Messaging (IM) Services", draft-ietf-
         enum-im-service-00 (work in progress), March 2006.

   [20]  Haberler, M. and R. Stastny, "Combined User and Carrier ENUM in
         the e164.arpa tree", draft-haberler-carrier-enum-02 (work in
         progress), March 2006.

   [21]  Livingood, J. and R. Shockey, "IANA Registration for an
         Enumservice Containing PSTN Signaling Information", draft-ietf-
         enum-pstn-04 (work in progress), May 2006.

















Uzelac                  Expires March 16, 2007                [Page 11]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


Author's Addresses


   Adam Uzelac
   Global Crossing
   1120 Pittsford Victor Road
   PITTSFORD, NY 14534
   USA
   Email: adam.uzelac@globalcrossing.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





Uzelac                  Expires March 16, 2007                [Page 12]


Internet-Draft     draft-uzelac-speermint-use-cases      September 2006


Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





































Uzelac                  Expires March 16, 2007                [Page 13]