Your Network's Edge®
Blog Post
You are here
SD-WAN – Unpacking the vCPE Platform
Jun 17, 2019
Prelude
This is the second of a three-part SD-WAN series by AvidThink on the evolution of SD-WAN, vCPE, uCPE and the emerging importance of the vCPE operating system. The first article examined the origins of the vCPE and SD-WAN. This second article focuses on the importance of the vCPE operating system, while the third and final article will discuss the future evolution of the vCPE platform.
Gen 2 SD-WAN utopia — tricky to achieve
At the end of our first blog post, we shared that CSPs were rolling out RFPs for the 2nd generation of SD-WAN deployments. The early adopters are refreshing their SD-WAN platforms to move to a white box uCPE solution that hosts multiple VNFs, one of which is the SD-WAN VNF.
However, many CSPs have realized that things are not so straightforward. Unlike commercial SD-WAN appliances, which are fully integrated and tested by the SD-WAN vendors, a uCPE/vCPE/VNF stack requires a lot more care and feeding than many CSPs expected.
Examining the disaggregated CPE stack
As an industry, we've touted disaggregation as an element of our move to SDN and NFV. The premise is that by breaking up what used to be a vendor-proprietary monolithic solution, we can reduce costs and increase business agility. However, to recreate a complete and useful solution, two things need to exist: first, we need to be able to get access to all the components that make up that solution; second, we need to have the expertise to pull together those components and ensure they work together. Beyond these, we likely need ongoing assurance for that integrated system and a strategy to upgrade each separate component as and when needed, or to swap in and out components that no longer meet our needs.
Generally speaking, to replace the CPE stack, we need:
- the white box hardware, the uCPE, with the same or better capabilities as the gray boxes or proprietary hardware.
- a vCPE operating system (OS), often based on Linux, and sometimes BSD UNIX, that provides operating system functions as well as the general NFV Infrastructure (NFVI) capabilities, including the hypervisor, along with cloud-based management and Zero Touch Provisioning (ZTP).
- the Virtual Network Functions (VNF) like vRouter, virtual firewalls, and of course, SD-WAN.
CSPs moving on to Gen 2 SD-WAN deployments have found that while the uCPE itself is available from multiple sources, and while many networking vendors supply their network functions as VNFs, vCPE OS choices are limited.
SD-WAN all-in-one appliances usually have an OS that performs ZTP and cloud management. And in some cases, their platforms may even allow hosting of third-party VNFs, usually security functions like next-generation firewalls from partner companies. However, these OSes are not provided as general-purpose OSes and therefore not fully open to end-users or CSPs. After all, the SD-WAN solution provider is selling an SD-WAN solution, not a vCPE platform OS. And so the number of providers for vCPE OS tends to be more limited than those providing white box uCPEs or VNFs.
The role of the vCPE OS
The vCPE OS is an essential element, providing the foundational software platform on which we run VNFs. It's probably more appropriate to call it a platform than just an operating system in that it is also expected to provide:
- Cloud-managed ZTP capabilities for provisioning and managing thousands of uCPEs in remote locations.
- Hardware and software troubleshooting, monitoring, and visibility capabilities.
- A hypervisor platform that supports hosting and execution of VNFs on top of the platform. Today these VNFs are packaged mostly as VMs, but we are seeing Linux container support and Kubernetes support starting to show up as roadmap futures.
- VNF management directly or in concert with other orchestration and management platforms such as NFV-O or VNFMs.
- Basic Linux bridge networking or some element of virtual switching, often with I/O performance enhancement. Usually, this is provided using OpenvSwitch with DPDK support (though PCI-passthrough, SR-IOV are usually available as well)
- A reliable firmware and software update mechanism that can handle corrupted images and disconnections during firmware updates, avoiding a unit swap or truck roll to fix the problem.
- Open and flexible APIs that allow for integration with other orchestration platforms, standard APIs include NETCONF/YANG and general RESTful APIs, as well as future support for standards like OpenConfig.
- Driver support for most common uCPE platforms. Some of these platforms have built-in integration with accelerated NICs for better I/O performance.
Given these requirements, just taking a Linux OS build and slapping it on a white box isn't quite enough. Further, a full bloated OS does not work for low-cost and power-constrained CPEs. Ideally, the vCPE OS is lean and resource-efficient. Additionally, we should also point out that the full set of capabilities aren't always required. For simple CPE deployments that only need basic connectivity and a limited set of network functions at the edge, and where more advanced functions run in a central location (i.e. the centralized vCPE model), all the VNF management and hosting capabilities are optional.
Waiting for DANOS
CSPs that AvidThink speaks with are usually surprised at the lack of open-source options for the vCPE OS. For those of us in the industry, it feels like there should be open-source options — and yet, there aren't. There are open-source components that one can cobble together, but many of us are still waiting for the arrival of Linux Foundation's DANOS, which is based on contributed code from AT&T's dNOS project. DANOS is meant to be an open-source edge platform OS with a routing stack in the form of the Free-Range Routing (FRR) project — another LF initiative — integrated. It's now six months overdue from its estimated Fall 2018 release date, but the LF indicates that progress is being made, and it will be available soon. Regardless, DANOS is unlikely to provide robust cloud-managed provisioning and management capabilities when it is first released, so it won't be a complete solution on its own.
For now, there are a handful of commercial providers that offer a vCPE platform with the varying subset of features we described above. The key is to understand the business requirements for your deployment and map them to the vendor capabilities.
I'm not a system integrator, I just play one on TV
vCPE OS choice aside, MSPs and CSPs are also now realizing that there is a new system integration role that needs to be resolved. When an SD-WAN deployment fails, whose responsibility is it to fix the problem? Is it the CSP? The vCPE OS vendor? Or the VNF vendor? The MSP or CSP is the natural choice for the responsible party since they are selling the SD-WAN solution to the enterprise. However, not all SPs have the in-house skill to troubleshoot the problem, and many may have to rely on 3rd-party system integrators to help them build and manage their SD-WAN solutions.
Beyond the vCPE OS
In this post, we've provided insight into the current role played by the vCPE platform, which we hope you've found helpful. In our third and final blog post, we'll examine how the vCPE platform might evolve and what to expect in the future, so keep watching this space for the next installment of this article series.
About AvidThink
AvidThink is an independent research and analysis firm focused on providing cutting-edge insights into the latest in infrastructure technologies. Coverage areas include 5G, AI/ML, cloud, edge and IoT, NFV, SD-WAN, SDN, hyper-converged infrastructure, and infrastructure security.
