One document matched: draft-uzelac-speermint-use-cases-oo.txt
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 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.
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]
| PAFTECH AB 2003-2026 | 2026-04-23 22:23:57 |