Your Network's Edge®
Blog Post
You are here
The Secret Origins of SD-WAN
Jun 03, 2019
Prelude
This is the first of a three-part SD-WAN series on the evolution of SD-WAN, vCPE, uCPE and the emerging importance of the vCPE operating system. In this first article, we'll examine the origins of the SD-WAN with respect to vCPEs and follow with a second article focusing on the vCPE platform; the third and last article will discuss the evolution of the vCPE and SD-WAN.
Software-defined networking (SDN) caught the networking community’s interest circa 2011, and network functions virtualization (NFV) emerged soon after. Collectively, we believed that the combination of these two initiatives could bring substential value to the communications service providers (CSP), but we sought an appropriate killer application to help energize the market. While CSPs dabbled with both SDN and NFV and ran proofs-of-concepts (POC) for virtual IP Multimedia Subsystem (vIMS), virtual Evolved Packet Core (vEPC), and other use cases, it wasn't until virtual customer premises equipment (CPE) and software-defined wide-area networking (SD-WAN) came along that we saw significant uptake of SDN and NFV at CSPs.
vCPE origins — the hot NFV use case
Before SD-WAN, there was the vCPE. The initial NFV concept for a vCPE, at least at many CSPs, was to take multiple physical network appliances at the customer premise and virtualize them into Virtual Network Functions (VNFs), so they could run anywhere on top of a vCPE platform. There were three general flavors of vCPE architectures in the original POCs:
- All Cloud: All VNFs were hosted in the cloud — points-of-presence, central offices or regional data centers — with a small footprint CPE device (e.g. a network interface device) on premises for establishing site connectivity.
- All On-Premises: All VNFs would run locally on a universal white box CPE (uCPE) on premises and VNFs would be downloaded, instantiated and executed locally.
- Hybrid: Virtualized network functions would span both the cloud and customer premises. Some VNFs would run locally — e.g., WAN optimization — while others could run in the cloud, where compute resources could scale more cost-effectively.
Quite a few early deployments subscribed to the All cloud approach, which had benefits of easier management, better scale economies, and faster roll-out, either by re-using an existing CPE, or through use of a L2 NID, handling most complexity in the cloud. We at AvidThink believe that this approach still has merit, especially for residential gateway services, because many of the business drivers for having on-premises VNFs don’t apply to home users.
The rise of SD-WAN
As vCPEs were being trialed, a new term emerged: SD-WAN. Before the term became popular, SDN as applied to the WAN was primarily about transport and inter-data center connection optimization — think Google’s B4 project. The term SD-WAN was initially ambiguous as to whether it referred to SDN applied to a WAN backbone or whether it applied to the next generation of the enterprise edge.
Very rapidly, SD-WAN solidified the next-generation update to the enterprise edge and has become a marketing clarion call to all businesses looking to innovate on their remote connectivity solutions. While the term is still ambiguous, standards and open-source organizations like MEF and ONUG are attempting to define it.
SD-WAN – Gen 1 vs Gen 2
While CSPs were working through their vCPE architectures and the VNFs that ran on those, businesses started deploying first generation SD-WAN solutions, usually in the form of dedicated appliances at the customer premises, which were typically grey boxes from original design manufacturers (ODMs), backed by direct support from the SD-WAN vendors. SD-WANs provided businesses with increased resiliency (multiple-links), improved bandwidth at lower cost points (augmenting or replacing MPLS with direct internet broadband), and other benefits (zero-touch provisioning, cloud management, improved security). Many of the functions SD-WAN subsumed were already part of existing proprietary CPE appliances, including routing, firewalls and even WAN optimization.
Once CSPs caught up with initial SD-WAN demand from business customers, they decided that they would drive SD-WAN vendors to package those as VNFs essentially running on top of white box CPEs. When they started putting out request for proposals (RFPs) for second generation SD-WAN deployments, they mandated a uCPE/vCPE/VNF stack. This meant they controlled the white box uCPE choice and the vCPE OS/management stack, and SD-WAN was relegated to being merely a VNF.
Gen 2 SD-WAN – not quite utopia yet
This Gen 2 setup allows CSPs to maintain control over the platform while providing business customers with their desired SD-WAN solution. The goal was to allow customers to pick and service-chain their favorite VNFs, or at the very least, freely choose from a subset of available VNFs carefully curated by the CSP. In this manner, SD-WAN VNFs could be swapped out as necessary, shifting the balance of power from the SD-WAN vendor to the CSP. However, as CSPs soon learned, things aren’t so straightforward. To learn more about the potential pitfalls and challenges with the second generation of SD-WAN, vCPE, and uCPE rollouts, stay tuned for part two of this three-part article series from AvidThink on RAD’s blog.
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.
