I’ve gotten a lot of recent questions from operators and others (even some on LinkedIn) about deploying service features (VNFs or otherwise) in carrier cloud or on “universal or virtual CPE”. This is a concern that dates back almost to the beginning of the NFV ISG work, and the tension between the two options has IMHO been a factor in diverting the efforts of the ISG to a less-than-useful path. Given these points, I think it would be useful to address the issue.
We should start by saying that service features have typically been created by inserting appliances into a service data stream. Firewall devices provided firewalls, in other words, and these appliances were called “physical network functions” or PNFs by the ISG. The principle goal of the NFV ISG was to define a model for hosting virtual network functions that substituted for PNFs. In the initial Call for Action white paper, the operators who launched the NFV work presumed that this hosting would take place on commercial off-the-shelf servers (COTS).
One of the service agility benefits quickly proposed within the ISG was the creation of multi-part services by the chaining of VNFs, and this gave rise to the “service chaining” interest of the ISG. A virtual device representing a service demarcation might thus have a VPN VNF, a firewall VNF, and so forth. Recently, SD-WAN features have been proposed via an SD-WAN VNF in the chain. All of this got framed in the context of “virtual CPE” or vCPE.
As a practical matter, though, you can’t fully virtualize a service demarcation; something has to provide the carrier-to-user connection, harmonize practical local network interfaces (like Ethernet) with a carrier service interface, and provide a point of management handoff where SLA enforcement can be monitored by both sides. Think of home gateways as an example; you need to have something that provides WiFi to the home, and that something has to be in the home. That’s true with at least some pieces of any service demarcation, and that almost immediately gave rise to the proposal that vCPE include both cloud hosting and hosting on a generalized premises device, something now often called “universal CPE” or uCPE.
Could you deploy a service chain of functions (VNFs) into a uCPE box, as though it was an extension of carrier cloud and using the set of features and capabilities the ISG has devised (and is still working on)? Perhaps, but the better question would be “Should you?” There are in my view some compelling reasons not to do that.
The first reason is a kind of appeal for logical consistency. The goal of the ISG has been to create, via virtualization and hosting, the software equivalent of a set of PNFs that could then be managed using traditional EMS/NMS/SMS tools. If we have a uCPE box, why would that box need special treatment to be so managed? There are a number of different ways we could stack software elements in a piece of uCPE, and all of them would produce, in an abstract sense, exactly the same virtual box with the same management properties.
And all of them would be better and more logical, too. Service chaining is a network-connection function, something you do to link cloud-hosted elements in a chain so they’d function as a single linear flow. There is no need for a network inside a device, which means that if you want to do uCPE hosting of a service chain, you have to either devise a method of providing a software linkage and then support that as a deployment alternative to a network link in NFV, or you have to force uCPE to have an internal network to chain the pieces.
I think both these approaches would be silly to say the least, but the whole uCPE issue raises what’s perhaps the most compelling question, which is whether you’d do a service chain even in the cloud. Suppose I have three possible software VNFs that might be combined to create a single piece of vCPE. You might say we have “firewall”, “VPN”, and “SD-WAN”. There are perhaps a half-dozen commercially meaningful combinations of those features. Why not simply create a unified VNF for each of those combinations?
There is no reason to have separate VNFs, which demand separate hosting, unless you can scale or replace them individually and gain some value. In a serial flow, I don’t think you can point out what the value would be. Furthermore, reliability theory says that if you need three independent serial elements for something to work, the chances all three will work is lower than the chances that a single element with all three feature sets would be working. And since separate hosting costs more, you’d be paying more for getting less. Service chaining never made any sense in a vCPE application, anywhere. To require it be supported and used for uCPE hosting of combination-VNF services would make even less sense (if that’s possible).
What I think this adds up to is that we do need the concept of elastic uCPE, elastic in the sense that it supports the insertion or replacement of feature elements. However, does it have to be implemented the way that “cloud-hosted service-chained VNFs” would be? No, nor is that idea itself even useful. What should be done, then?
The answer is that we need to go back to abstraction, the key to virtualization and the cloud. If we have the concept of virtual-device and if we assign properties to things of that class, which include the property of recognizing feature-slots into which we can insert feature-components, then uCPE is defined as it needs to be. The “object” uCPE represents must then provide for the insertion of components into slots, but exactly how that happens is inside the black box of abstraction and nobody knows or should care.
We’ve had the software support for this underlying principle of abstraction for decades. I recall the introduction of the concept in programming with the Modula-2 language back in the early 1980s, in fact. You would first define an abstract component with its external properties, then the implementation of that component. This same approach was carried into Java, the most popular programming language today. It’s the way software-think has gone for a long time, and so it’s clear that the current vCPE/uCPE approach is a regression into device-think. That’s surely off-target when we’re supposed to be at the dawn of the software-defined age in networking.
Many vendors and operators know all of this; some have been more outspoken than others, but my own contact with both groups shows the awareness of the problem (and the solution) pretty clearly. The challenge is that the commercial benefits for doing the right thing aren’t clear, and so vendors are understandably not eager to poison the market when operator spending is already threatened. Future transformation and future spending depend on somebody eventually driving this, and it may have to be the operators themselves.