Introduction
SDN/NFV concepts have already changed fundamentally our market not by its number of implementations but on all the new concepts of services promised to us. Unstable and fast moving evolutions in Open Source innovations compared to better consistency found with proprietary solutions have made SDN/NFV to stall. SD-WAN has been accelerating the process of implementing Software-Defined services with the promises of providing a mission-critical applications based connectivity, mitigating with various access technologies, ensuring service assurance and advanced services such as ZTP (Zero-Touch Provisioning), Embedded Zero-Touch security, Embedded Service routing with or without tunneling technologies, real-time connectivity service restoration, etc…
SD-WAN Router software relies naturally based on a different service infrastructure including notably a SD-WAN Service Controller and some service analytics tools that are associated with the SD-WAN controller policies and actions to provision a service.
However, as any other customer premises oriented technology, SD-WAN still need to reside over physical resources aka whiteboxes that could either be vCPE (Virtual CPE) or uCPE (Universal CPE). The two notions slightly differ in terms of technology used and the expected outcomes and evolution that the customer desire. How can we differentiate these two notions ?
Especially, when we consider various notions that could blur the understanding of how vCPE or uCPE could deliver the expected promises of agility, flexibility and cost reductions. Different factors such as SD-WAN, Multi-Cloud or Multi-VIM, disaggregated networks and even orchestration and automation can be impacted by these two notions.
Comcast has recently announced that they were working on a uCPE solution that could run multiple VNFs with its SD-WAN solution. How and which impacts on future networks ?
What is vCPE/uCPE ? How do they differ ?
On one side, the vCPE (Virtual CPE) concept conveys the idea of a single VNF (Virtual Networking Function) that will be supported over a Customer Premise Product, whereby, a limited interest will be for other VNFs. By definition, a cost-effective and lower-performing CPU is generally considered as the base element. Most services and applications are coded towards Intel, therefore ATOM / Denverton are often used and associated with a lower amount of RAM memory and a reduced disk capacity. Additionally, some customer Premises functions are also proposed for LAN and SD-WAN purposes : WiFi, LTE and PoE (Power over Ethernet).
As a result, the vCPE approach lacks in scalability to accommodate additional VNFs because both ATOM/Denverton don’t support hyper-threading option, brings more LAN capabilities (Supplementary LAN ports, WiFI, LTE and PoE) notably for SD-Branch but remains a costly solutions because of the additional costs generated by LAN associated functions. The typical installation of a VNF for vCPE software is generally done in a Bare-Metal approach.
On the other side, the uCPE (Universal CPE) concept conveys the idea of Managed Services therefore that multiple VNFs (Virtual Networking Functions) have to be supported at customer locations. However, this consideration of multiple VNFs or CNFs running at the same time was limited but purposely adapted for a short number of applications/services required to run at the customer premises. Amongst which : Unified Communications & Collaboration, Session Border Controller (SBC), Anti DDOS, Video PVR, Firewall.
To satisfy the requirements for scalability, uCPE platforms generally opt for Xeon-D that supports Hyper-threading capability. To maintain a line of cost-effectiveness, uCPE platforms generally restrict themselves with limited LAN ports and almost no LAN feature options such as WiFi, LTE or PoE. A typical implementation of uCPE and multiple VNFs, will require a NFVi solution meant as a mitigating virtualization layer to allow multiple VNFs to share hardware resources.
Why NFVi is important for uCPE and how does it differ from Bare-Metal in vCPE ?
By definition, to instantiate a given software over a whitebox platform there are two ways to approach a straight install aka Bare-Metal or using virtualization with tools like KVM over a LInux distribution. Now, the intent with uCPE is to have multiple VNFs that will be cohabitating together leveraging the same physical resources and facilitating the collaboration between them to formalize a sense of customer managed services. This is where the notion of NFVi (Network Functions Virtualization infrastructure) comes in.
The NFVi concept is to allow a virtualization layer to be made available to accommodate more than one VNFs to be instantiated over given hardware resources but also that could be managed, orchestrated/automated and Service chained. Generally, NFVi solutions reside either at the DC/CO or in a disaggregated methodology at the PoP and edge locations. Usually, they require high-processing power (OpenStack / VMWARE), separate both Dataplane and Control Plane and evangelize multi-tenancy options. Otherwise, they favor micro-services, performance and light-weight footprint for Cloud Native capabilities (Kubernetes/Docker).
However, at customer premises, a lightweight version of a NFVi is an absolute requirement alongside with a bunch of important features : VNFs & CNFs support / DPDK & OVS support for both VNFs and CNFs to overcome Kubernetes and Linux flannel limitations / Standard OpenStack and Docker APIs through REST structure / Netconf & Yang model to allow the NFVi to support SFC (Service Functions Chaining) and a VNFM (VNF Manager) mode of operations and facilitate the interaction with the Orchestration layer (NFVO, SDN-C) and the virtual links between VNFs/CNFs deployed also called Service Chain, which is likely to be hybrid therefore composed of both VNFs & CNFs.
On a vCPE mode, the methodology is rather simpler because the SD-WAN or vCPE software, will inherently provide the RestFul APIs for higher layers interaction, Netconf & Yang models for interfacing with VNFM/NFVO, SDN for SFC interfacing. This simpler approach brings a natural incline towards a limited number of applications residing at customer prems. However, it reinforces the need for processing-hungry applications to reside at the PoP or CO and to ensure very strong SLAs and KPIs to monitor the health and quality of experience (QoE) on a per application basis.
Orchestration and automation, how SD-WAN converge towards SDN/NFV ?
As we have all witnessed, SD-WAN has now reached a market consensus as THE service concept meant to supersede IP-VPN connectivity in Access networks. Interestingly, SD-WAN brings a lot of interests as it can used as an overlay service-oriented over all access technologies imaginable : Fiber, Copper, Docsis, 4G/5G, Satellite and even over a Public network approach (Internet) encompassing the lack of Quality of Service in Internet-based networks.
The main obstacles about SD-WAN are generally made about the facts that it is a monolithic and a lock-in kind of technology, which comes with its entire silo service approach with router software and orchestration and analytics offering. A natural impression is to consider that SD-WAN doesn’t converge with other VNFs or CNFs that could instantiated besides it.
The Orchestrator function of SD-WAN aka SD-WAN Controller or Conductor responsible for instantiating the SD-WAN router software on whiteboxes, pushing the service policies towards the SD-WAN routers deployed, generates a lot of questions. Indeed, any controller function needs to be incorporated within the entire service infrastructure notably : OSS/BSS, NMS and Service Assurance or monitoring function and the Inventory mechanisms (CMDB like) for hardware and software license tracking capabilities. Such an effort is not trivial but we still have to remind ourselves that SD-WAN is not SDN/NFV and only a fraction of other services that could associated with a SDN/NFV based service infrastructure.
There is nowadays a natural incline to SD-WAN vendors to join forces with Orchestrator vendors to ensure a proper interfacing using RestFul API and to adapt their Netconf/Yang model to facilitate TOSCA blueprints to leverage as best as possible all capabilities that SD-WAN could offer. For Open Source MANO (OSM) oriented vendors it offers the perfect example of what SDN/NFV should be : flexible and agile. More importantly, TOSCA provides a very fast access to automated options that can accelerate the monetization of both SD-WAN and any other VNFs/CNFs. Any OSM vendors leveraging TOSCA with their solutions or with a home-made implementation of ONAP, open-up a faster access to new revenues and differentiated services and attracts a lot of interests in the market.
Most recently, I heard that there is a growing number of SD-WAN Conductor/Controller solutions which are converging towards SDN/NFV Service Orchestration capabilities. Which could be considered as an even faster access to converge SD-WAN and SD-NFV. However, it brings the natural questions of maintaining a line of openness and freedom of choice for our customers and considering their future ability to introduce new services, new innovations without being blocked or restricted to innovate of they see it fitting their forward-looking perspectives.
How vCPE/uCPE impact Disaggregated Networks and the Managed Services notion ?
Edge computing and Disaggregated Networks generally comes together as two general concepts that are unlocking the decentralising capabilities in networking and service infrastructure combined. Since 2000s and the inception of MPLS, we’ve seen services to converge and being aggregated over a unique networking platform where services will be aggregated at the edge and centralized at the Core network. The era of Cloud and Datacenter has been following the same reasoning where by service functions could be virtualized nonetheless centralized at a core location of service infrastructures. So, we can naturally say that the edge has always been a critical place for the Service Adaptation layer to groom and deliver traffic and services from and to the end-users (Business and Residential).
The Disaggregation of networks and services emphasises the idea that centralizing applications and services couldn’t be sustained due to different aspects :
Scalability :
Power consumption, power hungry applications, exponential growth of users, international coverage requiring a need for better quality of experience, inability to cope with high latency and jitter, Nodes Manageability and orchestration over immense scale etc…
Flexibility :
Activation of customer services in rapid fashion, ability to cope with rapid changes or activation of additional sites, monitoring and service management of distant sites over a last mile collaborative service provider, rapid onboarding of new services.
Efficiency of Orchestration Layer functions:
There is a major debate about SDN and Orchestration efficiencies on the ability to imprint changes from the Overlay perspectives down to Dataplane level. It reflects the ripple effects of intended-orchestration or automation where the instantiation of VNFs/CNFs or leveraging SDN to create, modify or tear down service circuits.
Manageability : With the substantial changes expected with the transition for 5G, it will generate an unprecedented acceleration of number of nodes to be managed. As I explained in my previous blogs, 5G evolution will profoundly modify the landscape of our market. Unlocking new possibilities of further solution options in IoT, Edge Computing, Disaggregated Networks, etc...
What are the perspectives for Disaggregated Networks ?
Every services or applications come with their respectives challenges and KPI criterias, that are both deriving SLAs and expected Quality of Experience. Therefore, with various transitions that are happening on the market, it looks a very daunting task to maintain all applications at the DataCenter or Central Office level. Subsequently, Service Providers of any kinds see MEC (Multi-Access Edge Computing) as a clear opportunity to leverage all their POPs (Points-Of-Presence) and distribute services at different layers of the service infrastructure. The ultimate goal of both disaggregated network and Edge computing is to find a balance to increase the Quality of Experience perceived by the end users. This simply means that some applications have to reside closest to the customers (Customer Prems) and others can still reside at Access PoPs or Aggregation PoPs.
Distributing applications across the Service Infrastructure, brings two additional important questions:
First, decentralizing applications and services between the DC/CO, Point-of-Presence and customer locations, can a single NFVi/VIM solution can respond to all my current service requirements and my requirements for obvious scalability for performance, density and variety of services that I intend to deploy ?
Second, how service and apps disaggregation can be sustained without the service intelligence to be distributed as close as possible to the customer-located uCPE solutions ?
Does disaggregation align itself with a single NFVi/VIM approach?
The closer the locations are to the DataCenter or CO, the more chances there are to see requirements for multi-tenant applications where customers can share resources with a virtual segregation. This set of requirements are naturally associated with OpenStack or VMWARE. Indeed, due to its inherent nature to be operating at the OS Kernel level, CNF (Containerized Networking Functions) handled and managed by Kubernetes/Docker are improper to provide multi-tenancy options.
Now, the closer the locations are to the end-users typically at the eNode-Bs or at the customer locations will see proper environments for a light-weight technology such as Kubernetes/Docker to spawn CNFs (Containerized Networking Functions) as fast as possible as well with the possibility to minimize the pressure of hardware resources to support these services. However, disaggregating networks doesn’t only means Mobile and a large variety of connectivity-based services could benefit from the disaggregation of functions and services. From GPON, DOCSIS, Microwave, ODTN and even copper could leverage these new decentralizing capabilities.
However, Kubernetes/Docker combined with Linux Flannel have inherent weaknesses that are limiting the flexibility and agility required to support Telecom use cases. Notably, the logical segregation between underlay and overlay traffics notably for SFC, ZTP and service changes over Netconf. Therefore, it required from market actors new innovative ways to either support OpenStack-like, for VNFs, but a lighter version with the flexibility of instantiating both VNFs & CNFs type services. Recent innovations coming from WindRiver to support both a light-weight OpenStack version with native capabilities over CNFs but also ENEA with its NFV Access solution combined with a uCPE manager are actually fantastic innovative tools that are fully embracing both OVS & DPDK to separate underlay and overlay services but also fully leverage RestFul APIs to facilitate the communication and interoperability with higher layers.
At higher layers, we now fully appreciate that one NFVi/VIM solution doesn’t satisfy to all requirements especially to the multiplication of customers that are asking for their Cloud-in-a-Box on Premise. This naturally brings a natural incline to solutions like ONAP and its Multi-VIM component, which put a lot of emphasis on the required flexibility to leverage set of APIs to take advantage of the differentiated approach on a per NFVi/VIM approach.
Networks disaggregation and Orchestration/Automation, can they provide all the required benefits for uCPE solutions
The disaggregation of networks is a methodology that derives the necessity of leveraging applications and services at their best locations to improve key elements of how customers see their rendered solutions : Latency / Jitter and Quality of Experience provided.
uCPE and vCPE have a direct effect on how the solutions can be perceived by end customers, notably, because there is a restricted group of applications that need to be located at the customer premises identified as managed services. Indeed, with physical CPEs the notion of managed services was delivered by pushing a physical per function but now with virtualization and containerization Service Providers now intends to deliver one physical and several functions to reduce mainly CAPex costs and better control over OPex. As a result, the option for vCPE seems to be inappropriately capable of supporting multiple functions simultaneously. Indeed, typical applications/services such as Voice or Unified Comms with Enterprise vSBC or vPBX, Security with vFW/WAF and Anti DDOS, vRouter would be ideal candidates of hosted applications onto a uCPE. Therefore, uCPE would be the ideal element to maintain the service demarcation line that separating the operator’s domain to the customer’s domain.
Taking advantage of applications & services disaggregation, would bring a direct advantage to accommodate other important apps/services, which are not critical to the customer experience but important services or apps to be deployed either centralized or the nearest PoP making sure that an adequate quality of experience for these 2nd tiered applications wouldn’t be compromised while maintaining a certain level of service assurance and agility.
Disaggregating applications & Services is one thing, what about the Service Intelligence ?
Moving applications from being centralized at DC/CO to be distributed across a given service infrastructure, implies other challenges. Indeed, for Service Providers, in order to monetize the virtualization/containerization of apps & services this requires to orchestrate (NFVO/VNFM) and automate (customer portal). Therefore, it brings the question of how service intelligence can be distributed alongside the applications and eventually to be instantiated, modified and naturally stopped in the blink of an eye.
Therefore, the same requirements that are required for apps and services to be closer to the end users apply to the Service Intelligence to be now closer to the same applications it will orchestrate and automate. Hierarchical orchestration will then be required to provide a centralized and bird’s view of the infrastructure that will be located at the DC/CO. Also, light-weight versions of the same orchestration capability could be distributed closer to the applications and services to provide local orchestration/SFC and SDN capabilities in adequation to ensure a great quality of experience as for when customers intends to create/add functions or service circuits, modify them eventually and terminate them finally.
This perspective of distributed orchestration and automation capabilities can be already overseen with ONAP (Open Network Automation Platform), which provide a Service Orchestration function serving as an E2E Orchestration component, which could be coupled with distributed functions like Virtual Function Controller aka VFC. The VFC component is already meant as a element that will interface with other components of ONAP such as Multi-VIM, NS (Network Services) catalog and ONAP TOSCA blueprints and Yang model. More importantly, the VFC will provide a viable interface to other MANO compatible NFVO and VNFMs that could be deployed via southbound interfaces and ensure a direct line of communication with the ONAP Service Orchestrator using a NorthBound interface.
ONAP and its most recent Casablanca release is already here and increased both the readiness to implement solid SDN/NFV infrastructure. So much so already, that service providers have already started to implement their own version of ONAP, software vendors have already taken actions to integrate ONAP and some of its components within their own orchestration solution and even Service Integrators have already announced that they will introduce an ONAP-as-a-Service Platform for any market actors willing to develop an Open Source approach far from proprietary and locked-in market options.
Besides SD-WAN, where does vCPE bring value : SD-Branch !!?
As you might have read in the previous pages, I am sure you might think that I am trying to destroy the interests of vCPE compared to uCPE. Despite the advantages that I have listed about SD-WAN, its next evolution leads to a new approach called SD-Branch. As I explained in earlier chapters, the vCPE aligns itself with entry-level Intel CPU technologies such as ATOM or Denverton that naturally decrease the scalability capability to support multiple functions at the same time. However, vCPE devices brings further options such as LAN/WAN functions, which typically are WiFi / LTE or PoE (Power over Ethernet) to supply electrical power to switches and IP Phones or Video-Conference phones.
The SD-Branch concept is a further evolution issued from SD-WAN, which consists in elaborating a new architectural approach that will combine both WAN and the LAN or branch functions into a single IP-based software that is supported by an unified Yang and Netconf model. Then, from the standpoint of a vCPE device, it enables the hosting of a third-party application (VNF or CNF) such as SD-WAN or vRouter combined with a set of branch/enterprise related functions. This would naturally required a virtualization or containerization of all layers at the branch with a seamless Yang and Netconf model that will deliver underlay and overlay functions, advanced networks and security services coupled with a centralized management/analytics and control (ZTP/ZTC) platform but supported by a distributed orchestration and automation solution.
An obvious question comes to mind, are the vCPE as it exists today or the uCPE provides the bare requirements to address both VNFs/CNFs scalability and the perspective towards the SD-Branch option ?
vCPE or uCPE, how do they effect on the Service Infrastructure layers ?
This is a very large question, which can only be answered at the mid-term and long-term perspectives. Indeed, all service providers address the market with certain bagages (past investments) which dictates what and how they invest into. Nonetheless, it is obvious that scalability of virtualized services will always be the main elements that will always be common to operators. Operators have the only objective to resell bandwidth or Mb/s. To maximize the value of Mb/s, operators have largely used the differentiation of services and applications combined with hardware assets. In the recent past years, hardware especially the ones located at customer premises have turned into pure commodity and are now even considered as a cost burden that need to be negated.
However, the need to increase differentiation and innovation brings the question of how new service infrastructures can be impacted from the choices made at my customer locations. This equation is not easy to tackle but vCPE provides a perspective of a single VNF or eventually dual VNFs while uCPE brings significant option for better throughput and multiple VNFs running at the same time. Therefore, centralized or disaggregated, service infrastructures must be flexible enough to allow the option of bringing additional services or apps to my customer service catalog without compromising the best Quality of Experience (QoE) because once again centralized or distributed my service and applications must always to guarantee my customer satisfaction and increase their market loyalty.
During my university studies, one of my teacher was repeatedly saying that a satisfied customer is a returning customer that can ensure revenue growth and customer loyalty.
Conclusion
In a recent past, we’ve witnessed a lot of activities that were involving the terms vCPE or uCPE with the aim of bringing massive costs reduction at network locations where most of the service nodes were deployed. Over a rapid cost calculation, even a minor cost decrease could mean a massive way to increase margin on a per service deployed especially for managed services and its customer demarcation line represented by CPE devices.
From the vCPE/uCPE conundrum, SD-WAN emerged as the simplest solution to tackle multiple questions at once :
* Superseding IP-VPN at Access networks
* Increasing the Quality of Experience on per application basis
* Decreasing costs while increasing margin on a per product or service deployed
* Accelerating the time to market for customers
But, one question still remains. Will SD-WAN and even its extension such as SD-Branch be enough ? I personally don’t believe that SD-WAN or even SD-Branch can sustain all services on its own and it will require other services alongside it to address all customer requirements. In such a case, I still don’t believe that vCPE or uCPE will have a winner but perhaps that a combination of the two concepts could the solution as I have proposed on some occasions to some of my operator customers.
Sometimes, I even faced questions that some customers would either be vCPE or uCPE customers, well possibly…
However, this will obviously dilute the volume for each vCPE or uCPE whitebox purchased making the economies of scale less interesting. However, the direction proposed by Comcast at the beginning of this article brings interesting challenges with very positive outcomes if approached correctly. At the end of it all, execution and decisions are the keys to succeed.
Written by Luc-Yves Pagal Vinette