The following is my Real CTO conversation with Kevin Riley of Sonus.
Prayson: Kevin, could you talk a little bit about your company’s role in the NFV transformation?
Kevin: Our primary focus at Sonus is migrating real-time communications to network functions virtualization infrastructure, or NFVI.
This focus manifests itself along multiple dimensions, including session border control, policy, modernized licensing models, cloud-based tool chains, lifecycle management of VNFs, and various disaggregation models for the NFV applications themselves.
However, on the surface, one might conclude Sonus is strictly an SBC company focused on delivering an SBC VNF. At Sonus, we view that as entirely inaccurate. NFV represents a new architecture that unlocks powerful new capabilities. In order to get there, though, we first need a solution strategy for NFV transformation. To me, as a CTO, adopting a solution focus is compulsory.
One of the main benefits of moving to a virtualized application is the ability to dynamically instantiate applications based on any number of business triggers. Yet, focusing on VNF functionality alone is not enough. Organizations really need to focus on delivering fully automated, elastic scaling models backed by licensing tied to network capacity and not directly to instances.
As an industry we also need to recognize NFVI is going to provide new capabilities to increase efficiency, such as resilient scalable cloud databases, resilient storage models, external storage models, dynamic VM scaling capabilities and health monitoring. As the industry moves to this new NFVI architecture, organizations have a lot of infrastructure they can take advantage of that may have previously had to embed in your application and develop on your own.
As a company, you need to recognize you’re moving from a static hosting model to a dynamic model and application behavior will become somewhat obscured. The tool chains that support the VNF become a critical component of the solution as applications may move and scale in real-time. It’s imperative to be able to assess VNF performance, troubleshoot and monitor the application SLA in a cloud environment without increased effort. Contrast that to the classic method of connecting to a node or attaching the debug console to a node to get a better understanding of what’s going on within the network.
If your company doesn’t get this right, you run the risk of having an innovative VNF that’s too difficult to deploy in this NFV architecture. As customers begin to make vendor decisions, the tool chains and solution components surrounding the VNFs are going to be just as important as the VNFs themselves.
Getting back to Sonus, a key part of our strategy is recognizing that SDN goes hand-in-hand with the NFV transformation. While SDN is becoming an overloaded term in the industry, we view SDN as the emergence of programmable IP transport, which in turn creates a unique opportunity to drive collaboration between the real-time session layer and the IP transport layer.
We currently live in a best-effort world where applications essentially do their own thing and assume that the network will deliver the required SLA. Some of our products, such as session border controllers, have historically been a bump in the wire, providing security and policy interworking, but after that we assume the transport’s going to do the right thing.
In the new world, the session border controller sits within a unique position in the network where it understands what’s going to happen for real-time communication when the application is about to invoke a service. We know exactly what that application is going to invoke and what is going to require of the networking layer. Through SDN, we can now start to program and control the network to realize that SLA that the application requires. As part of this transformation with NFV, we see SDN playing a complementary role as the industry migrates to this new architecture.
Prayson: You made some very interesting points about architecture implementation and I want to take the discussion up a level. With your long background in voice applications, I’d be curious to hear if you think that this move to virtualization provides a rejuvenation of the value of voice. You mentioned collaboration. Do you think that SDN and NFV provide an opportunity for enhanced voice and data integration or interesting voice data mash-ups? How do you see the applications being driven by these new technologies?
Kevin: I love this question. One way of thinking about virtualization is that it makes voice portable. Devices are no longer boxes in a fixed place of the network. They’re now services that can be involved within the Cloud infrastructure. As voice becomes more portable with other services in this new Cloud NFV-enabled infrastructure, my expectation is that we’re going to start to see communications become embedded in other applications such as Salesforce, LinkedIn, Twitter, or other web-based user-facing applications.
As organizations move to NFV, and voice turns into a software application, it’s easier to enrich the user experience, which will rejuvenate voice. Moving to a proper software model gives IT managers the ability think, “how can I embed voice to enrich the user experience?” For me that’s one area that provides a rejuvenation of voice.
Another area of change for voice will be where it “runs” in networks. I wouldn’t classify this as a rejuvenation of voice, but more of a change of how voice is optimally delivered to the end-user to maximize their experience. We’re going to see the data center expanding, and the network edge (and even the customer premise) will start to virtualize and become NFV hosting environments. Effectively, the datacenter is extending closer to the user. And as that starts to happen, I believe we’re going to see voice and voice services move from the core to places in the network where they’re most optimally located.
In the mobile space there’s a movement called “mobile edge computing.” It’s similar to the way NFV started with a lot of service providers getting together and writing a whitepaper of what they envision the next generation core architecture to be. The mobile space is envisioning moving services much closer to the edge for optimal routing, optimal handling, and optimal delivery to provide the end-user with closer delivery. We’ll begin to see a disaggregation of centralized architectures and relocations of applications that are integral to the user experience closer to the consumer. NFV is the facilitator for that move. If these were boxes, you would never drag them to the network edge, but as they become virtualized software applications, they become more portable and more relocatable.
That’s going to drive rejuvenation around the classic voice delivery architecture. Rather than just taking the core and virtualizing it, now you can start thinking about a disaggregated core and where you most optimally place these VNFs.
I also want to comment briefly on how Unified Communications (UC) is really driving a rejuvenation of voice. We see UC ramping aggressively and it’s forecasted to continue to do so for the foreseeable future. It’s changing the way we work, the way we collaborate and now it’s starting to become embedded in our standard work tools and processes. Again, another pull-through for driving more real-time voice on the network.
UC is a real-time application that’s driving the on-ramp of voice, video and content share. All of these functions require session control, interworking and security – this lands right in Sonus’ wheelhouse. If we look at NFV, we agree that it’s ramping, it’s a complex service and that there’s voice pull through. So why is NFV important to UC?
We’re using the NFV model to change UC. UC will still be deployed on-premises, but there’s a big push by the major UC players to move UC-as-a-Service (UCaaS) delivered from the Cloud. Instead of owning the app, companies move to a subscription model, letting UC be delivered by the owner of the application (whether it’s Microsoft, Google, BroadSoft or Mitel).
NFV is a critical technology to enable this new business model for UC providers because the most preferred model for UCaaS is to deliver the full service from a Cloud infrastructure, entirely in software, which is exactly what NFV migration of real-time VNFs delivers.
I see the movement of UCaaS to the Cloud as another huge pull through for the rejuvenation of voice and that’s only possible if you underpin it with NFV.
The last point I’ll make on this is about connecting the application to the IP transport, which ties back to voice and data integration.
Sonus has managed to deliver communications in the most demanding network conditions, which is real-time. It’s highly sensitive to latency and sensitive to packet loss. If you’re in a call that has poor quality, you are going to hang up quickly. It’s a very logical step to broaden the scope of your service delivery strategy and architecture to include data in non-voice applications. That’s exactly what Sonus is working on as part of our expanding NFV strategy.
The benefits of an SDN-managed networking in real-time are clear. There are many mission-critical applications delivered within enterprises that are just as important as voice – such as Salesforce, your CRM, customer portals, or a license server. These are critical applications that have to work. So as we move into this converged domain where we’re seeing a flattening of networks (voice is folding into the same networks as data). It’s the sharing of bandwidth with critical enterprise applications that becomes even more important.
Companies and vendors need to take a more homogenous approach so advanced strategies that are focused on optimizing the user experience are not just for real-time, but mission critical applications in general. Essentially, companies need to drive a hosted view of how voice and data should be architected. NFV and SDN are the key technologies that allow us to harmonize that user experience in both the voice and data domain.
Prayson: Great points Kevin. Here’s the hard question: As we improve the user experience with voice and implement strategies to make it more portable, can we actually get our teenagers to use the voice feature on their smart phones?
Kevin: (laughs). That’s a tough one. Our teens are certainly driving lots of WhatsApp traffic and IM traffic and we’re also starting to see a big push into multimedia. With teens posting videos and short clips to “capture the moment” we’re seeing more chat rooms and interaction within groups of tweeners and teens. It’s important to note, this demographic will embrace technology much faster than we will. Teens are beginning to move into things like Instagram and Periscope — basically wanting to communicate and share their experiences in a way that’s much richer than an SMS text. It’s going to take them back into the world of real-time voice and video for communications with each other. I do see those two overlapping and evolving.
Prayson: As you have started into applying these technologies to enhance voice and data communications, UC and the other aspects, what are the obstacles that your company is working to address?
Kevin: There are two main challenges and they revolve around the current capabilities of the NFV infrastructure itself, and the efficiency of x86 Intel platforms for real-time media processing. Those are really the two areas Sonus has been working through.
Regarding the first challenge: the cloud infrastructure in general initially evolved to support web-based applications. As we move real-time applications into this infrastructure, such as SBCs, video conferencing applications or UC stacks, you start to find out if there’s sub-optimal behavior in this infrastructure that needs to be addressed. These types of behavior can be fixed through a work around or engagement with the development community to effectively add capabilities that are suitable to a wider range of applications.
In the case of Sonus, the majority of challenges fall into the networking domain. These are areas such as IP network access, reconfiguration and support of VNF resiliency, and other bottlenecks that add latency and throughput issues. There are also simpler issues like public network addressing, and how to build it into your cloud infrastructure for VNFs that need to be directly reachable by the user endpoints or outside world. Essentially, Sonus sees challenges within the infrastructure domain that we’ve been working through.
The second challenge we worked through is the efficient processing of packets at very high arrival rates in a pure Intel x86 environment. Our applications typically process very small voice packets that arrive very quickly. In some cases they’re larger video packets, but they still arrive at a modest packet rate. Our VNF in particular needs to provide high-scale functions such as DDOS protection, packet forwarding, overload controls and media interworking.
To combat this challenge with the VNF architecture, companies need to think about segmentation so that their highest duty cycle algorithms, are decoupled from the application proper, and run independently as lightweight, highly optimized tasks.
An example of such an algorithm is initial stage packet classification, i.e. determining what’s good versus bad and warrants further processing, and transcoding. If you can achieve this segmentation in your architecture, these high duty cycle tasks can be scaled and ramped in a way that has almost zero interference with the rest of the application, driving deterministic behavior. This segmentation allows us to minimize the processing we have to do at that high rate, including the filtering and payload manipulations. The rest of the application can operate at a much slower rate once you digest what is good, what is bad, what requires further processing. That’s been an architectural challenge that Sonus has had to work through just by nature of delivering a real-time application into NFV infrastructure.
Prayson: That partitioning, that segmentation and decoupling, does that also facilitate the use of multiple cores or multiple processors to achieve that scaling?
Kevin: Absolutely, organizations can take advantage of affinity rules and capabilities within the infrastructure itself to really lock down functionality where appropriate, where required and most importantly drive that deterministic behavior. Sonus has found if you port a real-time application over and fire it all up as everything running in a single container, with some number of virtual CPUs following a Linux symmetric multiprocessing model, and assume the operating system’s going to do the proper balancing, you quickly get into trouble in NFV software environment. Whereas before you had dedicated hardware elements that have a very deterministic behavior that could handle those high frequency operations. It is imperative that companies design software architectures utilizing segmentation, affinity rules and multi-threading models.
Prayson: Sonus is fortunate to have a large installed-base of customers that you can work with as you migrate to NFV and SDN. Based on your interactions with those customers, when do you think NFV will hit critical mass for carrier-class applications?
Kevin: When I think about NFV, I see two main applications for our type of customer.
The first is NFV activity at the service provider edge. When I say edge, I mean the edge that faces customers, the access edge of the network and customer premise. Quite often, that is referred to as virtualized CPE.
The second application is Cloud core, which is really turning what was a hardware-based static core network architecture into a flexible virtualized architecture based on NFV and SDN principles.
On the first: the reason service providers are so interested in virtual CPE is that when they turn up business class services, they typically have to send someone on site and turn up a SBC, a router, a firewall, and maybe a few other boxes. What CSPs want to do is streamline that model, minimize truck rolls, and make it as low touch as possible to accelerate service turn up and reduce OPEX associated with that service turn up. They view NFV and virtualization as the vehicle that gets them there.
I’ve seen several large CSPs already move in this direction and start to build this into their offer. In terms of architecting it in, building the proper systems that deploy NFV at the cloud edge or on-prem as virtual CPE, I think we’re right at the beginning of the on-ramp as we have several large Tier Ones that have built this into their service offer. In my opinion, as we move into 2016 we’re going to see the on-ramp of NFV activity at this cloud edge and at this on-prem under the umbrella of virtual CPE.
On the second front: What I’m currently seeing is a lot of early lab engagements for core Cloud. I believe customers are still working through the right recipe as there’s no proven template for mission critical real-time NFV at scale yet. I expect between now and the second half of 2016 we’ll continue in this mode.
What Sonus is doing is establishing ourselves as having the right NFV architecture and engaging the CSP as being part of the solution definition via POCs, technology sharing and solution adaptation as we figure this out together.
Prayson: As you’ve been working with your customers in the rollout, what’s been the one thing that’s been most surprising or unexpected?
Kevin: The CSPs that Sonus interacts with are committed to moving to NFV. They know they need to get there to drive new service offers. It might be more expensive for CAPEX initially but over time they expect to save on CAPEX and OPEX. The main draw is being able to create new service models where you can deploy fast, fail fast and test new services. Additionally, they can increase the capability to drive more personalized services to customers.
I think the piece that’s been a little unexpected is some of the roadblocks that we’re seeing within organizations. I see the CTOs aligned with NFV, laying out goals and timeframes to make the transition happen. I see the architecture teams getting behind it. I see the network realization teams getting behind it. The barriers we have to push through now are the operation teams. These are the teams that own the performance of the application, the people whose livelihood depends on those applications meeting an SLA and a certain level of reliability in the network. Those teams have a fear that software can’t work as well as what they’ve been managing and running in hardware. One of the things I didn’t expect was how strong that pushback has been in some organizations such that it has slowed down the progress toward NFV. With some of these CSPs the focus has now shifted from pushing on their vendors to be ready and come forward with solutions, to enlisting the vendors to help win over the ops teams and show the ops teams that miracles don’t have to happen to replicate this in software and turn up these services. The technology is there today to make this happen. In several engagements Sonus has been enlisted as advocates with these groups to help win over the operations teams to show them that this technology can work.
Prayson: That’s helpful. Kevin, thanks for your time today. We appreciate it very much.
Kevin: My pleasure.