Finding the right NFVi migration path to virtualized "open" services

As a matter of fact, network functions virtualization is already on the path to reshaping the telecommunications industry, together with other technologies such as software defined networking (SDN), delivering on the promise to help service providers reduce costs, better automate processes and be ever more flexible in their service deployment models.

The payback of virtualization is huge. It provides a newfound level of agility to restructure services at both the core and edge networks and work towards significant operating savings.

For most operators the pressure is most certainly on to accomplish a NFV migration initiative, to be one of the leading providers who is first to get that “competitive advantage”. But it cannot happen overnight and still have clients expect the best possible service.

One of our goals here at Kontron is to make sure organizations can put more focus on servicing customers and worry a little less on the technologies behind the service. We do this by doing all the heavy lifting of integrating the various Kontron and/or partner hardware and software into turnkey solutions that are, in some cases open source systems, and ultimately interoperable with other 3rd party software.

Imagine loading a single system (2U) into a rack and within an hour or two have a fully functioning redundant OpenStack environment ready to provision VMs across your legacy (or new Kontron servers) compute resources.

So what better way to jump-start a plan for NFV infrastructure than having a major piece of the puzzle already worked out. Since OpenStack is the de facto layer to provision virtual network functions (VNFs) across virtual machines, Kontron conducted validation work with various OpenStack distributors and singled out Canonical as a key partner who closely adheres to the ‘open source’ mission.

However, since OpenStack is driven by an open source community it means there are regular updates to worry about. The key is service providers should choose a partner, like Kontron, that also does the continuous integration. For NFVi, we see that most providers are typically focused on the Long Term Releases (LTR) that are updated every two years and supported for five. This gives them a more long-term, stable plan while still reaping the benefits of the work achieved from the open source community.

This is essentially how a phased migration can be a successful journey.

So, no vendor lock-in. And, that's not just lip service. A single SYMKLOUD OpenStack Platform can deploy multiple VNFs from multiple vendors and scale VM workloads across other high density SYMKLOUD platforms.

A perfect example is a recent collaboration with GENBAND during its Perspectives17 Annual Customer and Partner Summit.

From their lab, GENBAND installed the SYMKLOUD OpenStack Platform built on the commercial-off-the-shelf (COTS) MS2900 Series platform. The built-in automation meant a fully redundant OpenStack controller environment running in minutes, from which they could deploy their GENBAND Advanced Media Software (AMS) and Session Border Controller (SBC) VNFs.

As the GENBAND VNF Manager could interact with our OpenStack environment, the GENBAND VNFs were up and running in quick succession, shaving several days of installation.

The reaction of service providers at the event was pure and utter astoundment. We were able to demonstrate how our solution can, not only adapt to a wide range of designs, but scale in any direction, whether one tore down or spun up VNF instances for real-time communication sessions across IP networks.

Working with a pre-built OpenStack platform opens up the doors for service providers to what other VNFs they wish to work with and make part of their ‘open services’.

It’s all about how we can help accelerate and simplify VNF deployments.

Another great example was back at Mobile World Congress 2017.

Kontron took the VNF ‘bull by horns’ and quickly deployed multi-vendor, free-to-download VNFs across the SYMKLOUD OpenStack Platform. The end result was a Fortinet vFirewall and a F5 vLoad balancer on one system managing end-to-end traffic with an enterprise-branch vCPE appliance featuring a Brocade vRouter.

It’s a simple proof-point to demonstrate how seamless the transition from legacy to virtual-built services can be managed.

It also shows the cost and performance advantages of de-coupling hardware and software so that service providers can achieve two key business objectives: regain control of their operational costs; and, improve their agility to sell new enterprise and consumer services.

The COTS hardware used to build the SYMKLOUD OpenStack Platform, is based on the MS2900 Series of 2U converged infrastructure platforms. It features nine modular server nodes, each with a single Intel Xeon D 1500 Series 10-core processor with dedicated memory and storage.

The Kontron OpenStack team configured it to house Canonical MAAS and Juju deployment, modeling and monitoring tools on one node, redundant OpenStack Controllers (Nova, Glance, Swift, etc) across three nodes, and redundant Neutron and DPDK acceleration across 2 nodes.

This leaves three nodes open to expand OpenStack services or use as pure compute resources.

This is what gets people giddy when they see this.

It’s this level of hardware density integrated with a fully managed open source software platform that means operators can, compared to any standard 1U commodity server, reap the benefits of a yearly operational cost savings of up to 60% and a rack-level space savings of up to 77%.

But another real differentiator is how Kontron takes to heart its mission to give operators the freedom to choose what and how they deploy new or existing services across carrier cloud infrastructure. We have meticulously committed to deliver “Open Source” solutions, devoid of any “Lock-In” strategies – the bane of this telecom industry.

But to borrow from the “it-will-take-a-village’ analogy, it will take broad industry collaboration to make NFV (and SDN) a mainstream success. So for our part, we have been quietly building up a repertoire of independent software vendors (ISVs) who have worked with us to test their VNFs on SYMKLOUD hardware.

We try to make it as easy as possible with our SYMLAB remote testing environment. It’s open to all VNF vendors and, likewise, any service provider from anywhere. All they need to do is make a simple request.

So what are your short-, mid-, and long-term plans to transition any of your services from PNF (Physical Network Functions) towards VNF (Virtualized Network Functions)?

Where have you had success and where might have you been overly burdened? Or, are you just at the early planning stages?