Considering a Virtual SBC? Consider This.

Session Border Controllers (SBCs) are vital to the security and performance of any IP-based real time communications application - whether provided by a dedicated SBC appliance or in a virtual configuration.  As enterprise networks and communications service providers move to a virtualized SBC architectural model, they must assure that all the features supported in an appliance-based SBC work as well or better in a virtual model.   Network planners and architects must also factor in how SBC virtualization can affect security, performance, and scalability.  

Businesses and network operators are moving to a virtual environment because it has the potential to reduce operational expenses by providing one common computing platform for many network and operational support applications and services.  By standardizing on fewer appliances in favor of a more versatile, server-based architecture, the IT staff has fewer kinds of devices to maintain and (hopefully) a common interface to manage multiple applications.  Virtual architectures also offer more elasticity to meet dynamic demand for the supported services because computing resources can be repurposed according to need.  

Deploying a virtual SBC offers the same business benefits found with other virtualized network operations.  Moving SBC functionality to a virtual environment can also offer the same features as an appliance-based architecture, provided planners understand and execute on what is alike and what is different in the two approaches.   

Virtual SBCs need to incorporate all the standard features found in an appliance-based SBC, and network engineers need to select a virtual SBC that does not compromise critical functionality.  Whether appliance based or virtual, SBC features must include:  

Theoretically, a virtual server and a purpose-built appliance should offer the same performance when delivering SBC features.  However, theory is not always reality and planners need to consider special factors in a virtual environment.  

First, the software architecture in the virtual model is important to assuring equivalent performance.  For example, even though the appliance and the virtual server are both computing platforms, when converting to a virtual server, the SBC software may perform better when segmented.  When signaling, media, and transcoding functions operate separately; the architecture enables dedicated processing to each function, thereby facilitating the performance of each unique operation.  

Second, the hardware platform selected can affect SBC performance.  The nature of RTC prescribes frequent interruptions, so a hardware platform should accommodate these interruptions in a way that does not compromise communications quality of service.  Some server platforms use hardware that may improve performance with some software packages; however, some software solutions can offer the same performance metrics regardless of the server platform. For example, depending on the platform, security performance might be improved when using a virtual server that incorporates hardware-based encryption / decryption chipsets rather than relying on the software for encryption.  IT planners should work with their suppliers to architect optimal software and hardware options.    

Next, end-to-end management, also a requirement for appliance-based models, needs to offer horizontal scale and elasticity that could have greater demands in a virtual environment depending on the scale of devices and services within the incorporated virtual borders because each component needs to work well together.  Defining end-to-end service management responsibilities is very important when working together with a cloud service provider that has adopted an NFV infrastructure. For example, a service provider offering a cloud-based UC service that incorporates a virtual SBC could manage all the security and performance service elements, leaving the enterprise IT staff to manage its own user profiles. 

Fourth, a virtual environment requires "orchestration" to operate at peak efficiency. Orchestration enables automated service fulfillment throughout the network across multiple computing devices and domains.   As enterprises and operators move toward a cloud environment, orchestration can accommodate parameters such as load balancing and service provisioning, turning up network services as needs change. Orchestration tools are typically incorporated as a third-party tool as part of a full-scale cloud infrastructure architecture so interoperability testing with virtual SBC vendors is paramount to successful deployment.  Inherent in a fully orchestrated environment, IT planners also need to pre-provision hardware capacity so that any software features can be added with a single mouse-click.  

The decision to virtualize SBC features and services is likely to be part of a strategic decision to enable a broader virtual-service architecture in the enterprise or carrier's network infrastructure.  Fortunately, network managers don't need to compromise on any features inherent in appliance-based SBC solutions.  However, network planners do need to allow for special considerations when moving to a virtual SBC so that performance is on par with purpose-built SBC devices.  IT managers should work closely with both hardware and software providers when building a virtual solution to assure peak network performance balanced with easy-to-use network management and operational tools.