More at http://cloudify.co/webinars/open-vCPE-framework-webinar.html Oded Nahum discusses the importance of the vCPE use case and why we need to make it more open. He also talks about why it makes financial sense for telcos to do this in the long term.

1. vCPE 2.0 – The Business Case for An Open vCPE Framework
CHANNELS
SPONSORED: SD-WAN 2 Network Virtualization
Containers 5 MEC 1 SDN 5 NFV 3 Cloud 5 Security 2 IoT 5G 3
 Hi, Jeremy 

2. Oded Nahum (https://www.sdxcentral.com/author/onahumgmail-com/)
January 27, 2017
8:00 am PT
Lots of virtual ink has been spilled describing the benefits of Virtual CPE (vCPE) (https://www.sdxcentral.com/products/virtual-cpe/). The thought of simplifying the complex
world of enterprise wide-area network (WAN) (https://www.sdxcentral.com/sd-wan/definitions/software-defined-sdn-wan/) has ignited the imagination of many network en‐
gineers and enterprise IT admins. The vision of being able to consume, configure, and manage the WAN and its services (https://www.sdxcentral.com/directory/nfv-
sdn/services/) through self-service portals and automation (https://www.sdxcentral.com/cloud/devops/) has made vCPE the most common network functions virtualization
(NFV) (https://www.sdxcentral.com/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, creat‐
ing 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 de‐
liver 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.
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)
The architecture looked something like this:
CHANNELS

3. Photo Source: Gigaspaces
Back in 2012, NFV (https://www.sdxcentral.com/nfv/definitions/whats-network-functions-virtualization-nfv/) surfaced and the evolution to vCPE started. The idea was bril‐
liant and simple: shift the functionality, value, and cost…
…from the network edges to a centralized cloud (https://www.sdxcentral.com/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
The new architecture looked like this:
Photo Source: Gigaspaces
So, Why Didn’t We Get the Expected Results?
Let’s explore what happened to our three main solution elements during this evolution.
CHANNELS

4. 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) (https://www.sdxcentral.com/nfv/definitions/virtual-net‐
work-function/) 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)
CHANNELS

5. 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.
Photo Source: Gigaspaces
Forward Thinking
CHANNELS

6. As Nati Shalom wrote in a previous SDxCentral (https://www.sdxcentral.com/cloud/definitions/software-defined-everything-sdx-part-1-definition/) contributed article, Open‐
ness is the way forward (https://www.sdxcentral.com/articles/contributed/openness-true-path-nfv/2017/01/) — I still believe that the logic of centralizing net‐
work 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 net‐
work functions (http://getcloudify.org/from-virtual-appliance-to-cloud-native-vnf-whitepaper.html) 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
(http://getcloudify.org/2016/12/06/hybrid-vnf-container-orchestration-kubernetes-docker-swarm-using-cloudify.html).
Photo Source: Gigaspaces
Future Proofing vCPE Models
CHANNELS

7. 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 specifica‐
tion 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 em‐
brace 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.
CONTRIBUTED ARTICLE DISCLAIMER
Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; not the editors and publishers.
While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDNCentral LLC cannot guarantee that in‐
accuracies will not occur. SDNCentral will not be held responsible for any claim, loss, damage or inconvenience caused as a result of any information within this site, or any information accessed
through this site.
The content of any third party web site which you link to from the SDNCentral site are entirely out of the control of SDNCentral, and you proceed at your own risk. These links are provided purely
for your convenience. They do not imply SDNCentral's endorsement or association. The copyright and any other intellectual property right and third party content belongs to the author and/or oth‐
er applicable third party.
Share:
Related Articles
Today’s Best Practices for Protecting the Distributed Network
Overcoming the Five Hybrid Cloud Adoption Challenges
Enterprise Data Center: Why Stop at Software-Defined?
Virtualization Fuels Rise of the Modern Mobile Network Operator
    
CHANNELS

8. Post Comment
About Oded Nahum
Oded Nahum is the Director of Customer Solutions for Cloudify in EMEA & APAC. For the last 20 years he have been busy challenging status quo, pushing bound‐
aries, expanding horizons, and achieving improbable outcomes. Having worked as a Solution Architect at Cisco, Systems Engineer at PLUMgrid, Product Specialist at
Citrix, and Technology Evangelist, Oded's has a proven track record in Networking and Cloud Technologies. His specialties include Cloud Computing, IaaS, SaaS,
NFV, SD-WAN, vCPE, Automation and Orchestration, MANO, CloudStack, OpenStack, LBaaS, WAN Optimization, SDN, Layer 2-7, Traffic Engineering, QoS, Applica‐
tion Delivery, Virtualization, and Application Monitoring.
Oded is also a frequent speaker at various technology events and meetups.
  
Leave a Reply
Logged in as Jeremy Hess. Log out?
Comment
CHANNELS