For SBCs, virtual is the way, but not the only way

Interest in virtual Session Border Controllers is rising, but not all virtual appliances are built the same.

Late September is a great time to visit New York City. It’s not too hot but not too cold, making it perfect for a stroll around Central Park. This week, though, is like no other in that Interop comes to the Big Apple. One of the big themes of Interop New York is the topic of virtualized services, also known as Network Functions Virtualization (NFV).

Much of the focus of NFV has been on traditional network services, but I have seen increasing interest in communications infrastructure, most notably Session Border Controllers (SBCs). SBCs have typically been available only as hardware appliances, but as interest in the technology has broadened outside of service providers and very large enterprises (that have networks like service providers), the demand for a virtual version has grown.

However, not all virtual appliances are built the same. As the momentum around NFV has grown, more vendors have released a wide variety of virtual appliances, making it tough for organizations to make a decision on what to buy. When evaluating a virtual/NFV-based SBC, here are the key things to look for:

  • Consistency of features across platforms. Not all vendors offer all features across all products. Sometimes vendors have certain features that are dependent on specific hardware. In some cases, a vendor may have acquired a product to create the virtual platform, or perhaps the vendor just rushed the product to market. From a buyer’s standpoint, it’s important to have all features available across all the products. For SBCs this is critical to ensure that there’s a common set of UC services available across all branch locations.
  • Common code base. In some ways this goes hand in hand with the above, but there are some differences. A vendor may be able to replicate key features even if the codebase is different, but that could cause some challenges down the road, particularly with ongoing management. Configuration management tools, scripts, and other third-party tools may not work the same across products. Also, even if the vendor can replicate key features today, there is no guarantee that new features and product upgrades can be done in any kind of synchronized way. The code base should be the same across all hardware, virtual, and software-based instances.
  • Easy migration from currently installed products. Virtualized SBCs are still in their infancy, and its likely customers are going to need to migrate from an older, hardware appliance to a virtual version. There’s also the possibility that customers may want to migrate from a virtual appliance back to a hardware appliance down the road. Whatever the migration path, this should be something that’s easy for the vendor to do. If it requires custom scripts, lengthy upgrades or a team of engineers to do so, it’s probably best to go in a different direction.
  • Product available in different hardware and software form factors. I know the industry is all gaga over NFV today, but it’s not always the right answer. Using a purely virtualized platform means the customer must go out and procure the hardware, ensure there’s enough memory, processor, that all the hardware components are compatible with the software, etc. Don’t get me wrong, there’s tremendous flexibility with this model but there are other options. In addition to a virtualized product the vendor should offer the software running on a pre-tested, validated server. This can help with compliance to specific standards (such as NEBS in telco) and take much of the tuning and tweaking out of the hands of the customer. The benefits of software with the ease of an appliance. Lastly, the vendor should offer a traditional, hardware-based SBC. For customers that require predictable performances, nothing beats a dedicated hardware appliance.
  • Integration of policy functionality. The primary use case for SBCs is to terminate SIP trunks. However, I believe that policy enforcement, typically done in a separate diameter router, will need to become part of the standardized feature set of an SBC. No one does this today, but I’d certainly push the vendor on the roadmap for this feature.

NFV is a powerful technology that can deliver on-demand services for almost any network service. It brings a level of agility to the network that’s never been seen before. The SBC is ideally suited to be virtualized and run as an “NFV” workload, and I believe we’ll see more innovation in this area over the next year or so. However, I do believe there will always be demand for dedicated hardware appliances for those that require the dedicated, consistent performance.

There’s no right answer in choosing between hardware and software, although I do believe the flexibility and agility of software will outweigh other benefits for most customers.


Copyright © 2014 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022