Internet DRAFT - draft-sohel-sipping-s-bc-concept-arch
draft-sohel-sipping-s-bc-concept-arch
SIPPING Working Group K. Sohel, Sprint
Internet-Draft H. Beech, Sprint
Expires: January 7, 2006 M. Evans, Sprint
R. Gagliano, Sprint
July 8, 2005
Conceptual Deployment Scenarios of Session/Border Control(S/BC) Functions
draft-sohel-sipping-s-bc-concept-arch-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 January 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Intellectual property rights (IPR) statement
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.
Abstract
This document illustrates various conceptual deployment scenarios of
Session/Border Controller (S/BC). The objective is to depict a provider's
architectural requirements of S/BC function deployment. The document will help
the IETF community to understand that S/BC functions can be deployed in the
network in scalable approach.
Sohel, et al. Expires January 7, 2006 [Page 1]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Information . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Reference Peering Interface. . . . . . . . . . . . . . . . 4
5. S/BC Deployment Scenarios . . . . . . . . . . . . . . . . . 6
5.1 Composed or Standalone S/BC . . . . . . . . . . . . . . . 6
5.2 Semi-Composed S/BC . . . . . . . . . . . . . . . . . . . 7
5.3 Centralized S/BC with MGCF . . . . . . . . . . . . . . . . 9
5.4 Centralized S/BC with CSCF . . . . . . . . . . . . . . . . 10
5.5 Distributed S/BC . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Sohel, et al. Expires January 7, 2006 [Page 2]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
1. Introduction
The IETF drafts [3] and [4] outline S/BC functions. The IETF draft [3]
illustrates two deployment scenarios: Network-Network peering and Access-Network
Peering. Both of these scenarios use composed S/BC that integrates signaling
control, media, routing, and management functions into a single (stand alone)
device.
Although current trend is to deploy standalone or composed S/BC functions in the
VoIP and IMS networks, there are advantages of deploying S/BC functions in
decomposed, centralized, or distributed configurations.
To reduce duplication of various network functions, and to improve scalability
and efficiency of networks decomposed, centralized, and distributed S/BC
configurations need to be considered in addition to the current composed
configuration.
This document depicts five S/BC configurations, and their corresponding
deployment scenarios. The document also briefly discusses merits of these
architectures. The objective is to depict a provider's architectural
requirements of S/BC function deployment. The document will help the IETF
community to understand that S/BC functions need to be studied in holistic
border protection architecture approach and can be deployed in the network in
scalable fashion.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in [7] and indicate requirement levels for compliant
implementations.
3. General Information
The Packet Technologies and Systems Committee (PTSC, formerly T1S1) of
Alliance for Telecommunications Industry Solutions (ATIS) is working on
Developing IP Network-Network Interface (NNI) Interconnect [5] and
Session/Border Control (S/BC) Function specifications[6].A contribution [8]
portraying examples of conceptual realization was submitted to ATIS-PTSC meeting
in Montreal, Canada, on June 13, 2005. This document is a revised version of the
contribution.
Sohel, et al. Expires January 7, 2006 [Page 3]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
4. Definitions
4.1 3GPP
The following 3GPP terms are used in this document.
CSCF: Call Session Control Function
P-CSCF: Proxy-CSCF
I-CSCF: Interrogating-CSCF
BGCF: Breakout Gateway Control Function
MGCF: Media Gateway Control Function
4.2 Reference Peering Interface
A network peering interface can be divided into four planes: signaling,
media, routing, and operation-managment. This document defines modules
performing these interfaces as Signaling Function (SF), Media Function (MF),
Routing Function (RF), and Operation & Management Function (OF).
A SF performs the signaling and control functions. A possible example of a SF is
a SIP Edge-Proxy or a SIP B2BUA. A MF performs media peering. A possible example
an MF is a Media Relay (MR) or an edge-router. An RF interconnects the routing
planes of two networks. An example of an RF is an interworking function that
mediates two similar or dissimilar routing protocols of two networks. Typically,
an RF is implemented in an MR or edge-router.
+-------+ +-------+
| IP | ------- ------- | IP |
| phone | <------> / \ / \ <------>| phone |
+-------+ | SF...........SF | +-------+
+--------+ | | | | +--------+
|Wireless| |Provider MF .........MF Provider| |Wireless|
|Network | <----->| | | |<-----> |Network |
+--------+ | A RF ....... RF B | +--------+
+------+ | | | | +------+
| | <------->MG OF ........ OF MG<-------> | |
| PSTN | | | | | | PSTN |
| | <-------> \ / \ / <-------> | |
+------+ SS7 ------- ------- SS7 +------+
Figure 1: Reference Peering Interface
Sohel, et al. Expires January 7, 2006 [Page 4]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
Some examples of above functions are presented in the following table:
Functions Examples
Signaling Function (SF) SIP Proxy, B2BUA, Session Admission Control (SAC),
SIP Interoperability, SIP Denial of Service (DoS)
protection, SIP Topology Hiding (THIG), and SIP
security, privacy and encryption.
Media Function (MF) VPN mediation, traffic engineering, policy
enforcement, rate shaping, bandwith broker,
bandwidth theft protection, data integrity,
transcoding, RTP translator, Network Address
Translation (NAT), and media security, privacy and
encryption.
Routing Function (RF) Routing protocol harmonization
O&M Function (OF) CALEA implementation; accounting, billing and
operational data mediation.
Sohel, et al. Expires January 7, 2006 [Page 5]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
5. S/BC Deployment Scenarios
5.1 Composed or Standalone S/BC
The composed or standalone S/BC combines SF, MF, RF, and OF functions
into a single device. The following figure shows the composed or standalone S/BC
configuration and its associated network architecture. Some functions such as
ENUM interoperability (ENUM) module may be located outside of the composed S/BC.
Provider B
--------- . . --------------------
/ \ . . / \ +-------+
| | . . | +----+ <--------->| IP |
| | . . | |CSCF| <.........>| phone |
| | . . +----+ +----+ | +-------+
| <---|--------------------|S/BC|---> | +--------+
| <........................| |...> <--------->|Wireless|
| | . . +----+ +------+ <.........>|Network |
|Provider A | . _ /\__ . | |ENUM | | +--------+
| | . / \ / \ . +----+ +------+ |
| <---------\ 3rd \----|S/BC|---> +-----+ +--+ +------+
| <..........|Party IP |...| |...> |Proxy|<-|MG|---->| |
| | . \ Network/ . +----+ +----+ +-----+ +--+ | PSTN |
| | . -------- . | |MGCF| <..|......>| |
\ / . . \ +----+ / SS7 +------+
--------- . . -------------------
--- Bearer (RTP/IP)
... Signal (SIP)
Figure 2: Composed or standalone deployment of S/BCs
............
. +------+ .
. | SF | .
. +------+ .
. .
. +------+ .
. | MF | .
. +------+ .
. .
. +------+ .
. | RF | .
. +------+ .
. .
. +------+ .
. | OF | .
. +------+ .
............
Figure 3: Composed S/BCs
Sohel, et al. Expires January 7, 2006 [Page 6]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
The advantage of composed S/BC deployment in the network is that one-
device solves all peering issues. Disadvantage examples of this architecture are
single point failure, bottle neck, architecture and traffic scalability, and
potential hot-potato routing scenarios. Some claim that this architecture has a
potential of N squared connectivity issue.
5.2 Semi-Composed S/BC
The semi-composed S/BC splits signaling and control functions (SF) from
the media and routing functions (MF and RF). An SF can be an S/BC which has only
the signal and control functions. MF and RF functions are integrated with an
edge-router or a Media Relay (MR). Operation and management functions (OF) may
be required in both components. ENUM function may be a separate entity. The
following figure shows the semi-composed configuration and its associated
network architecture:
. Provider B
--------- . ------------------
/ \ . / \ +-------+
| | . | +----+ <---------->| IP |
| | . | |CSCF| <..........>| phone |
| | . +-----+ +----+ | +-------+
| <------------| SF |---> | +--------+
| | . +-----+ <---------->|Wireless|
| | . +- MF + RF-+ <..........>|Network |
| <............| MR/Edge |..> | +--------+
| | . | Router | |
|Provider A | . +----------+ |
| | . | +------+ |
| | . | |ENUM | |
| | . | +------+ |
| | . | +-----+ +--+ +------+
| | . | |Proxy| <-|MG|----->| |
| | . | +----+ +-----+ +--+ | PSTN |
| | . | |MGCF| <....|.......>| |
\ / . \ +----+ / SS7 +------+
--------- . ------------------
--- Bearer (RTP/IP)
... Signal (SIP)
(Control interface between SF and MR/edge-route is not shown)
Figure 4: Decomposed S/BC Depolyment Architecture
Sohel, et al. Expires January 7, 2006 [Page 7]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
............
. +------+ .
. | SF | .
. +------+ .
............
|
|
| (Control protocol e.g. H.248)
|
............
. +------+ .
. | MF | .
. +------+ .
. . Edge-router or Media Relay
. +------+ .
. | RF | .
. +------+ .
............
Figure 5: Decomposed S/BC configuration
This one-to-one solution (SF and edge-router (MF + RF)) provides engineering
flexibility for individual border points (variable relationship between SF
computing capacity and MF bearer capacity) and deployment flexibility through
the opportunity to place functions at different network locations (MF in an edge
router, SF in a data center). However, it requires two devices per interface
(border point) and introduces the requirement of additional external control
links. On the other hand, in a composed S/BC the MF:SF is internal, protected,
low latency interface. The Decomposed S/BC solution retains the stand-alone S/BC
disadvantages of single point of failure, architectural scalability, and
potential hot-potato routing behavior.
Sohel, et al. Expires January 7, 2006 [Page 8]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
5.3 Centralized S/BC with MGCF
This configuration integrates SF functions with the Media
Gateway Controller Function (MGCF) in a Soft-switch architecture.
Edge-routers integrate MF and RF functions. Operation and management functions
(OF) may be required in both components. ENUM function may be a separate entity.
The following figure shows the centralized S/BC with MGCF configuration and its
associated network architecture.
. . Provider B
--------- . . -------------------------
/ \ . . / VoIP \ +-------+
| | . . | <------->| IP |
| | . . | <.......>| phone |
| | . . +------+ | +-------+
| <-----.-----------------|MF+RF |--> | +--------+
| | . . |Edge | +------+----+ <------>|Wireless|
| <.......................|Router|...>| | | <......>|Network |
| | . . +------+ | | | | +--------+
|Provider A | . _ /\__ . | | CF |MGCF| |
| | . / \ / \ . +------+ | | | |
| <.........\ 3rd \...|MF+RF |...>| | | +--+ +------+
| | . |Party IP |. |Edge | +------+----+ <-|MG|--->| |
| <----------\ Network/---|Router|--> +------+ +--+ | PSTN |
| | . -------- . +------+ | ENUM | <........>| |
\ / . . \ +------+ / SS7 +------+
--------- . . -------------------------
(Control connection between CF and media-relay/edge-router is not shown)
Figure 6: Centralized S/BC functions deployment with MGCF
This one-to-many (SF and MF+ RF) implementation of S/BC functions in a soft-
switch architecture provides architectural and traffic scalability advantages
because one SF is associated with multiple media-relays or edge-routers(MF+ RF),
resulting in fewer signaling elements with broader control of media (MF)
resources. The association of SF and MGCF functionalities seems to provide a
rational functional alignment as they both control media functions. This
architecture may introduce additional complexity that must be addressed by the
SF to distinguish between access networks and to perform the appropriate NAT
functions on signaling and bearer data for each access network. Analysis for
signaling attacks needs to be performed properly in the SF. Intelligent
network-layer queuing, rate-limiting, and policy functions that support
wire-speed IP forwarding engine need to be implemented in the MF. Robust
coupling between SF and MF needs to be performed to implement appropriate
security. For that appropriate control protocols or SIP extension needs to be
developed.
Sohel, et al. Expires January 7, 2006 [Page 9]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
5.4 Centralized S/BC with CSCF
This configuration integrates SF functions with the Call/Session Control
Functions (CSCFs) or Breakout Gateway Control Function (BGCF) in a IMS
architecture. Edge-routers integrate BF and RF functions. Operation and
management functions (OF) may be required in both components. ENUM function may
be a separate entity. The following figure shows the centralized S/BC with the
CSCF configuration and its associated network architecture.
Provider B
. . -----------------------------
-------- . . / VoIP/IMS \ +-------+
/ \ . . | <------->| IP |
| | . . | <.......>| phone |
| | . . +------+ | +-------+
| <---------------------|MF+RF |--> | +--------+
| | . . |Edge | +------+----+----+ <----->|Wireless|
| <.....................|Router|...>| | | | <.....>|Network |
| | . . +------+ | | | I | | +--------+
|Provider A| . _ /\__ . | | SF |BGCF|CSCF| |
| | . / \ / \ . +------+ | | | | |
| <.......\ 3rd \...|MF+RF |...>| | | | +--+ +------+
| | . |Party IP |. |Edge | +------+----+----+ <-|MG|--->| |
| <--------\ Network/---|Router|--> +------+ +--+ | PSTN |
| | . -------- . +------+ |ENUM | <........>| |
\ | . . \ +------+ / SS7 +------+
--------- . . ------------------------------
(Control connection between SF and MR/edge-router is not shown)
Figure 7: Centralized S/BC with I-CSCF/BGCF at Network Interface
\/
|| +--------+ +---------+
Cell tower || | MF+RF | | |
|| <------>| Edge |<------->| |
| Router | | SF |
+--------+ | |
\/ |---------|<--> Other IMS
|| +--------+ | | Entities
Cell tower || | MF+RF | | P-CSCF |
|| <------>| Edge |<------->| |
| Router | | |
+--------+ +---------+
Figure 8: Centralized S/BC with P-CSCF at Access Interface
Sohel, et al. Expires January 7, 2006 [Page 10]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
This one-to-many (SF and BF+ RF) implementation in IMS architecture
provides architectural and traffic scalability advantages because one SF is
associated with multiple (BF+RF)s, resulting in fewer call control elements with
broader control of media (BF) resources. The association of SF and CSCF
functionalities (specifically between the SF and I/P-CSCF functionalities)
appears to be a rational alignment of border signaling functions. Integration of
SF and I/P-CSCF or BGCF functionalities might also reduce network complexity
through a reduction in call control elements. This architecture may introduce
additional complexity that must be addressed by the SF to distinguish between
access networks and to perform the appropriate NAT functions on signaling and
bearer data for each access network. Analysis for signaling attacks needs to be
performed properly in the SF. Intelligent network-layer queuing, rate-limiting,
and policy functions that support wire-speed IP forwarding engine need to be
implemented in the MF. Robust coupling between SF and MF needs to be performed
to implement appropriate security. For that appropriate control protocols or SIP
extension needs to be developed.
5.5 Distributed S/BC
In this configuration, SF, MF, and RF functions are distributed across
the network devices. For example, an (MGCF+CSCF) device integrates some SF
functions, an edge-router integrates some MF functions, and a fire-wall (FW)
device integrates some SF and MF functions. The following figure illustrates the
distributed S/BC configuration and its associated network architecture.
Provider B
-----------------------------
. / VoIP/IMS \ +-------+
P . | <-------->| IP |
r . | <........>| phone |
o . +---+ +------+ | +-------+
v .------------| |----|MR/ |--> | +--------+
i . |FW | |Edge | +------+----+----+ <------>|Wireless|
d .............| |....|Router|...>| | | | <......>|Network |
e . +---+ +------+ | | | | | +--------+
r . _ /\__ | | SF |CSCF|MGCF| |
. / \ / \ +---+ +------+ | | | | |
A ...\ 3rd \..| |.|MR/ |...>| | | | +--+ +------+
. |Party IP | |FW | |Edge | +------+----+----+ <-|MG|---->| |
.---\ Network/--| |-|Router|--> +------+ +--+ | PSTN |
. -------- +---+ +------+ | ENUM | <.........>| |
. \ +------+ / SS7 +------+
. -----------------------------
(Control connection between SF, MF, and FW are not shown)
Figure 9: Distributed deployment of S/BC functions
Sohel, et al. Expires January 7, 2006 [Page 11]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
This architecture may introduce additional complexity that must be addressed
by the SF to distinguish between access networks and to perform the appropriate
NAT functions on signaling and bearer data for each access network.
This architecture has scalability and operational advantages similar to the
preceding case, with the possible addition of better alignment between border
control and existing IMS functional decomposition. For that appropriate control
protocols or SIP extension needs to be developed as protocols between firewall
and other devices.
6. Security Considerations
Many of the functions this document describes have important security
and privacy implications. If the IETF decides to develop standard
mechanisms to address those functions, security and privacy-related
aspects will need to be taken into consideration.
7. IANA Considerations
This document has no IANA considerations.
8. Acknowledges
The ATIS-PTSC-SAC meeting held on June 13, 2005 at Montreal, Canada provided
valuable input to this document.
9. References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] G. Camarillo et al., "Functionality of Existing Session Border
Controller (SBC)", Internet-Draft, February 2005.
[4] M. Bhatia et al., "SIP Session Border Control Requirements",
Internet-Draft, January, 2005.
[5] ATIS PTSC, IP NNI Inteconnect standard (work in progress),
Issue Number S0009
[6] ATIS PTSC, Session/Border Controller Functions and Requirements (work in
progress), Issue Number S0024
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, March 1997.
[8] Khan, Sohel, "Example Conceptual Realization of S/BCs",
PTSC-SAC-2005-213, ATIS-PTSC, June, 2005.
[9] 3GPP IMS standard - 3GPP TS 23.002 V5.12.0 (2003-09) – Network
Architecture
[10] 3GPP2 IMS standard - X.S0013-000 Multimedia Domain Overview
Sohel, et al. Expires January 7, 2006 [Page 12]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
Authors' Addresses
Sohel Khan
Sprint
6220 Sprint Parkway
Overland Park, KS 66251
U.S.A
EMail: Sohel.Q.Khan@mail.sprint.com
Hal Beech
Sprint
6220 Sprint Parkway
Overland Park, KS 66251
U.S.A
EMail: Hal.s.Beech@mail.sprint.com
Mark Evans
Sprint
1 Adrian Court
Burlingame, CA 94010
U.S.A
EMail: Mark.x.Evans@mail.sprint.com
Roque Gagliano Molla
Sprint
6100 Sprint Parkway
Overland Park, KS 66251
U.S.A
EMail: Roque.Gagliano@mail.sprint.com
Sohel, et al. Expires January 7, 2006 [Page 13]
Internet-Draft Deployment Scenarios of S/BC July 8, 2005
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Sohel, et al. Expires January 7, 2006 [Page 14]
