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]