The Evolving Role of Session Border Controllers

By Aashu Virmani, Sonus Networks

Session Border Controllers, or SBCs, have come a long way since they were first conceived as an independent element in IP networks almost a decade ago.  While their original purpose still rings true – providing secure, controlled IP connections across IP borders – much has changed in their scope and function, including the definitions of borders themselves.

For the first few years of their existence, the industry debated whether a separate network element was even required, or if this functionality could be added to routers and switches.  For all but the smallest-scale SBCs, this debate seems to have been settled.  Originally, SBCs largely provided two key functions: connectivity and security.  The connectivity part had to do with NATing and protocol repair, and security had to do with topology hiding, encryption and prevention of DOS attacks.  However, as service providers and enterprises began deploying more advanced real-time applications over IP – such as Unified Communications, video, instant messaging, and conferencing – SBC functionality began to grow. Connectivity and security alone are simply not enough. SBCs must also provide:

• advanced call routing
• session admission control
• session quality-of-service enforcement
• fax and media interworking
• call pre-emption and media forking for regulatory compliance
• call detail records for accounting purposes.

All of this makes it fairly justifiable for an SBC to be its own, standalone network element.  More than that, the set of borders an SBC must police can now be characterized under several distinct headings: A Peering SBC typically connects two service providers; an Access SBC sits on the service provider side and terminates enterprise/access connections; an Enterprise SBC is typically deployed on-premise; and a fourth, new kind of border is emerging that I like to call the “Applications SBC" – one that sits between the service provider and the over-the-top application providers (Google, Skype) and enables co-opetition and trust between the service provider and the applications that use the service provider’s network.

Why all this fuss? Can’t we agree that they are all SBCs?  Isn’t the basic functionality the same, just deployed for different means?  True. However, it turns out that the performance and scalability requirements differ substantially from border to border. As an example, the Access SBC may be far more concerned with NATing – a very significant performance drain on the number of session attempts per second, versus a Peering SBC where one might be far more concerned with holding up the maximum number of connected sessions and providing the right media interworking.  Some experts might further break down a peering SBC into Wireline peering and Wireless peering deployments due to the kind of codecs for which an SBC must provide interworking. Similarly, an Applications SBC might be most concerned with employing the right QoS and policy enforcement for a given traffic type, rather than worry about codecs or NATing, for instance.

I won’t repeat any of the well-known growth stats about IP sessions, or Video, or IPv4 to IPv6 interworking that abound the net, other than to mention that this puts a further performance strain on the SBC function.  The important thing to take note of is the function an SBC is providing (in terms of the border), and measure it for what is relevant for that border type. As a general rule, SBCs will need to be flexible and scale independently across three dimensions – in their ability to provide advanced call routing and policy enablement capabilities, in their ability to perform wire-speed packet inspection and signaling message manipulation and in their ability to transcode media from one format to another. If the purported explosion in IP services materializes by even a small fraction, SBCs relying on general purpose computing to perform all three functions might find themselves a bit lacking in this new world of SBC 2.0.

Aashu Virmani, senior director of marketing at Sonus Networks, is an almost 20-year telecom industry veteran with extensive product and corporate marketing experience.  Prior to Sonus, Virmani served as a director of core network strategy for Motorola and lead marketing for mobile video infrastructure startup Aylus Networks.