If as I’ve suggested in the last week or so, vCPE is most likely to drive NFV adoption in 2016, then what happens with it is pretty important. It’s interesting then that we really aren’t saying much about vCPE models and issues. As we head for a major year of trials and testing, I think we should open a discussion on the topic and review some significant developments. In fact, I propose to use three developments as a foil to address the issues.
There are two basic models of vCPE deployment. In one, the hosting of virtual functions takes place in an edge device that acts as a kind of local, customer-specific, NFV Infrastructure (NFVI). In the other, hosting takes place on conventional servers in the cloud. It appears, based on carrier comments, that the former model has the best chance of gaining broad acceptance in 2016. The reason is that cloud-hosting requires a cloud, meaning a reasonably efficient and conveniently placed resource pool. In early deployments it could be difficult to provide that without shoveling a bunch of servers out to major offices and hoping for customers to justify it. With edge-hosted NFV, no pool is needed and costs are incurred only when you get orders.
Edge hosting also simplifies NFV management issues, because the primary resource for function hosting isn’t shared. You don’t have to apply complex deployment policies to decide where to host something, and once it’s hosted then all the hardware involved in the function is in a single place, represented by a single management point. The fact is that one of the best things about edge-hosted vCPE is that it really doesn’t have to look much like NFV at all…at first. In the longer term, there are three challenges associated with edge-hosting vCPE.
One is multiplicity of platforms. It would be easy to develop a vast set of alternative edge devices to host on, each with their own hardware features, software platforms including middleware, and their own VNF-hosting requirements. VNF vendors and operators might find so much edge diversity that just figuring out what version of a VNF to make or run would be a formidable task.
Challenge number two is the need to support migration to pooled resources as usage grows. NFV has little value if all it does is create feature-agile edge devices. Eventually operators will either develop vCPE opportunity to the point where central hosting is justified, or create resource pools for other missions (NFV or otherwise) that offer low unit costs. In either case, you have to be able to move the functions when it makes economic sense.
The third challenge is administration of VNF licenses. Operators will be acquiring virtual functions under a variety of commercial terms, ranging from per-use to flat fee. They’ll likely have to be able to account for where they’ve deployed VNFs and quite possibly what they deployed them on, and this accounting will have to work both for edge-hosted vCPE and for central hosting.
On the platform-multiplicity side, we had a couple of interesting announcements recently. Wind River has been working with virtual function partners (Wind River’s early partners include Brocade, Check Point, InfoVista and Riverbed) to develop a reference design for business-targeted edge-hosted vCPE platforms. Called “virtual business customer premises equipment” or vBCPE, the reference design would standardize the software platform on which VNFs run. This would almost guarantee that any device based on the reference design would run the same set of VNFs. Since the reference design could be implemented as a small on-premises server or a cloud server, it would cover both models of vCPE deployment.
Overture Networks has a somewhat different approach to the platform problem in its Ensemble 2.0 release. The Overture Connector is essentially a software-based business service dmarc device that includes data path, protocol, and control functionality to build a business overlay on top of any Ethernet or IP termination. It’s based on CENTOS and KVM, and includes not only VNF deployment features but SDN control and VNF connection capabilities. The Overture Connector can also be deployed on virtually any standard server, so it could be used at the edge or in the cloud as well.
I think that Wind River and Overture have gone about as far as you can go at this point to create a vCPE platform model. I remain concerned about cloud-hosted VNF deployment policies and management and operations connections, but these would likely have to be addressed in central VNF management. Overture’s Ensemble is one of the six products I believe could make the NFV business case, and Wind River is an infrastructure partner of HPE, another of those vendors.
HPE is also the source of the third announcement, a catalog-and-partner-centric vision for VNF deployment. The jumping-off point here is the reality that vCPE (or any kind of NFV service) is likely to be based on a catalog of deployable elements, selected for use either by a customer service rep through an operations tool or by the customer through a web portal.
HP’s service catalog is designed to let either customers or CSRs pick compatible VNFs from a list, and then launch these VNFs onward through deployment into use. HP plans a three-tier VNF partner program to represent various levels of certification, with basic onboarding stuff representing Tier One moving to advanced lifecycle management and OSS/BSS integration in Tier Three.
This is interesting because it represents a kind of top-down vision of 2016-target vCPE deployment support, from a vendor whose products can make the business case for NFV overall. Overture, I’ve noted, has similar business-case-making breadth. If both these vendors are going to promote a vision of vCPE that could be expanded into full operations integration and agile service creation, then it is possible that the OSS/BSS vendors aren’t the only players who could unify NFV trial-and-PoC silos down the line.
The Wind River approach, and particularly the Overture one, raise another question, which is whether purpose-built edge-hosting platforms for vCPE are a better bet than a server platform. Overture seems to have evolved its own view from purpose-built to server by offering agile software to run on pretty much anything. Can we build specialized CPE that would offer better features or value without doing stuff that would then tend to lock VNFs into the edge-hosted model and foreclose future cloud migration? That point needs to be tested, and I think the vCPE space is evolving to make that testing possible.
I’d sure like to identify as many pathways to a complete NFV business case as possible. I have to admit that I’m still uncomfortable about the notion of deploying “NFV” in vCPE form without any specific notion of how you’re going to tie the result into a broad NFV commitment. To be sure, there will be operators who don’t expect to make such a commitment (managed service providers are the best example, but even a full-service common carrier might see NFV useful only to augment carrier Ethernet services, for example). Most don’t feel that way, though. Of 57 operators I’ve talked with in some detail only three indicated limited NFV deployment was “acceptable”. These three developments don’t insure that vCPE can evolve into “real NFV” but they do facilitate that evolution, and that’s a good thing.