vCPE 2.0 – The Business Case for An Open vCPE Framework

This article was originally published on SDxCentral on January 27, 2017.

Lots of virtual ink has been spilled describing the benefits of Virtual CPE (vCPE). The thought of simplifying the complex world of enterprise wide-area network (WAN) has ignited the imagination of many network engineers and enterprise IT admins. The vision of being able to consume, configure, and manage the WAN and its services through self-service portals and automation has made vCPE the most common network functions virtualization (NFV) use case.
Another major driver is the cost savings from using low cost CPE devices and network services delivered over the top. For CSPs, it’s also about eliminating site visits, creating flexible service options, automating service creation, and virtualizing assets.
On paper this plan looked perfect. However, when we started deploying these solutions we realized that reality is more complex. Additionally, the vCPE services failed to deliver promised savings, and in some cases they were more expensive and lower quality.
In this post, I will try to demystify the vCPE cost model and offer an alternative way of building a vCPE solution that’s more cost effective and innovative, future proof, and provides the flexibility and adaptability that CSPs need in order to remain relevant.

Register today for our live Open vCPE Webinar on Feb 16!  Go

Show Me the Money

To better understand the CPE cost model and the evolution to virtual CPE, let’s look at how WAN services have traditionally been delivered. WAN services are built around three elements; the CPE, the network, and the telco delivering the service. Price was based on the functionality, value, and reliability of the services built into the CPE device and the associated network connectivity, bandwidth, and service offering. Therefore, enterprises wanting reliable services had to invest in expensive CPE boxes and reliable network services (MPLS).
Here’s the math: Service (CPE + Network*) x Number of sites = Total cost per site/month.
*Network refers to type (e.g., MPLS), bandwidth, and service (e.g., MPLS VPN)

Back in 2012, NFV surfaced and the evolution to vCPE started. The idea was brilliant and simple: shift the functionality, value, and cost…

• …from the network edges to a centralized cloud
• …from hardware to software-based functions
• …from MPLS to over-the-top (OTT) networking and direct Internet access
• …from labor-intensive delivery to self-service and automation

So, Why Didn’t We Get the Expected Results?

Let’s explore what happened to our three main solution elements during this evolution.

The CPE

Prices dropped and market commoditization is underway. However, we cannot yet deliver functionality similar to a traditional CPE with a $50 white-label box. Major network vendors have no incentive to support this evolution, and in fact, are making it difficult by bundling the service with a specific, proprietary CPE device.

The Network

Most vCPE solutions leverage OTT networking like software-defined wide area networking (SD-WAN) which—in theory—drive down the cost of bandwidth. As Enterprises are offered OTT networking solutions from non-traditional service providers and networking vendors, traditional CSPs will be forced to adopt this technology and cannibalize existing WAN revenue streams.

The Cloud / VNFs

This is a challenging and misunderstood problem. It’s expensive and complex to run virtual network functions (VNFs) while delivering a positive service experience.
Let’s take a deeper look at this. There are a variety of network functions needed to build an enterprise WAN Service offering:

• Routing Stacks
• Security and unified threat management
• Quality of service
• Application visibility
• Content management
• And more….

Legacy networking vendors that built their solutions on dedicated hardware are being forced to quickly adopt a software model. Most vendors took the easy way by simply offering a “virtual appliance.” This takes the same code base as the hardware solution and runs it in software on a hypervisor. Most of these virtual appliances inherit the same behavior as their hardware ancestors, those being:

• Closed or proprietary management interface
• Lack of service and capacity elasticity
• Legacy cost model and licensing
• Heavy virtualization footprint

Let’s put these elements in our cost formula again: Service (CPE + network + VNF) x Number of sites = Total cost per site/month.
The addition of a VNF element to the cost formula is challenging and largely misunderstood. To find out the real cost of the VNFs we need to include costs for:

• VNF licensing
• Virtual infrastructure (CPU, RAM, storage)
• Management and orchestration

First-generation vCPE solutions are driven by legacy networking vendors promoting a turnkey solution. Their solution provides the CPE with the network gear, the VNFs, and the orchestration framework. These solutions promise:

• Faster time to market
• Lower up front costs
• Open application program interfaces (APIs)
• Turnkey integration

Turnkey = Lock-in

These first-generation solutions have a dark side: lock-in. Turnkey vCPE solutions are just another kind of “networking box” that is closed, expensive, and tightly locked into the vendor’s revenue model. We end up with a solution in which the savings of CPE commoditization and OTT networking are outweighed by the cost increase of legacy VNFs and the infrastructure needed to run them.

Forward Thinking

As Nati Shalom wrote in a previous SDxCentral contributed article, Openness is the way forward — I still believe that the logic of centralizing network functionality and value is the right way to build vCPE models and achieve the promised cost model. But the only way to get there is by opening up the model to use innovative, cloud native functions. This next-generation vCPE will be built on network functions adhering to the following principles:

• Standard based and model driven
• Simplified and streamlined on-boarding
• Service and capacity elasticity
• API Driven
• Open and extensible
• Use a cloud economics cost model

An Early Open Source Option

The vCPE framework powered by open source cloudify is an open NFV orchestration platform enabling CSPs to deliver next-generation vCPE solutions based on these principles. CSPs can build vCPE solutions leveraging any CPE device, use any network service and facilitate on-boarding of any VNF. The next-generation, cloud-native network functions market is growing fast. We’re already using functions that deliver enhanced services at a fraction of legacy infrastructure and licensing costs. Rapid development is also happening in the adoption of container technologies for network functions.

Future Proofing vCPE Models

The open vCPE framework emphasizes orchestration and model-driven service design. This is radically different than turnkey solutions designed “bottom up,” which start with stack components and build an orchestration framework designed to work only with these components. Cloudify model-driven, topology and orchestration specification for cloud applications (TOSCA)-based orchestration takes a “top down” approach. It assumes the components of a service will change over time but the service and the way it’s orchestrated don’t.
This philosophy has several advantages:

• Easily adopt new technologies (VNFs)
• Service agility
• CSP service differentiation
• Enhanced user experience
• CSP solution ownership

Why Operators Need an Open vCPE Framework

Commercially, successful models must adopt a framework that drives cost reduction of all solution elements—from the CPEs, the network, and the VNFs. They must embrace fast technological innovation to unlock new opportunities, capabilities, and models that CSPs can benefit from. The only way to build the network of the future is to keep it open.