But virtualized network functions, running on commodity hardware, deployed at customer premise or at the provider edge, quickly becomes a much more complicated proposition where “the rubber meets the road” – in live network deployments.
Here are some challenges that operators are encountering:
Limited Connectivity Capabilities: Most off-the-shelf vCPE/uCPE hardware features Ethernet ports to connect to the WAN, but little more. This is a serious impediment because most service providers operate multiple access media in their footprint, and want to deploy vCPE services across as many of these media as possible – including mobile/wireless technologies to cover more remote enterprise locations. Ideally, customer premises hardware should be able to serve all locations, regardless of available access media, without requiring additional box appliances to be deployed. Smart SFPs available in the market can be used for this purpose.
Closed Solutions, Limited Interoperability: Stitching the service chains together from different VNFs is proving to be harder than expected, and requires lengthy and costly interoperability testing. This can usually be alleviated by the vCPE solutions vendor pre-testing and integrating the VNFs from different vendors, and ensuring open APIs exist for all tested VNFs.
Lack of Carrier-Grade Availability: Ensuring carrier-grade reliability that adheres to SLAs currently offered to enterprise clients requires ensuring redundancy and sometimes hardening of the hardware platform itself. Enterprise-grade COTS hardware usually falls far short of these requirements. Same applies to the software – the OS, VNFs, and service chains composed of these VNFs must be redundant, and the whole software solution must be architected with redundancy in mind.
Security Challenges: vCPE blurs the lines between enterprise and service provider network, therefore the security of all elements of the solution must be carrier-grade and assured. In legacy, physical CPEs, security of CPE hardware and software was the responsibility of the hardware vendors exclusively. In vCPE deployments any of the parties (vCPE solution vendor, VNF vendors, SP itself) can be responsible for the solution. In the case of fully open sourced solutions, integrated by the SP, the responsibility of maintaining security, with associated CAPEX and OPEX, falls on the SP.
Automation: vCPE solutions are much more complex and dynamic environments than legacy physical CPEs. vCPE solutions must be automated to fulfill the promise of OPEX savings and greater agility and flexibility. SPs usually lack in-house expertise and resources to develop customized automation solutions, and off-the-shelf automation tools are usually built for data center and enterprise use, not for SP networks.
The above challenges define the space that vCPE vendors like Rad and others in the space have to fill. To ensure SPs achieve their goals with vCPE, a vendor must provide a flexible choice of connectivity options, ensure carrier-grade availability, security, and openness of the solution, and provide automation tools to ensure vCPE services are deployed dynamically and efficiently.
This article was published by GlobalData Principal Analyst Emir Halilovic and can be found here https://www.rad.com/blog/vcpe-more-challenging-than-it-seems
