Suppose we decided that it was time to think outside the virtual CPE box, NFV-wise. The whole of NFV seems to have fixated on the vCPE story, so much so that it’s fair to ask whether there’s anything else for NFV to address, and if so what exactly would the other options look like.
vCPE has two aspects that make it a subset (perhaps a small one) of NFV overall. One is that it’s been focused on hosting in a general-purpose box that sits on the customer premises, outside the carrier cloud. The other is that it’s a single-tenant, single-service model. The first point means that unless NFV moves beyond vCPE, NFV can’t promote the carrier cloud overall. The second means that it’s very difficult to extend NFV to anything but business services, which limits bottom-line impact. If these are the limitations, then we should expect that “extended” NFV has to address both.
In theory, there’s nothing to prevent “vCPE” from being virtualized inside the carrier cloud, and many operators and vendors will hasten to say that even as they focus on premises-device-based implementations. The practical truth is that unless you have a fairly extensive edge-hosted carrier cloud in place, it would be difficult to find a good spot to put the vCPE VNFs other than on premises. You don’t want to pull traffic too far from the natural point of connection to add features like firewall and encryption, and any extensive new connection requirements would also increase operations complexity and cost.
There’s also an incremental-cost issue to address. A service has to be terminated in something, meaning that it has to offer a demarcation interface that users can consume, and whatever premises features are expected for the service. An example is consumer or even small-branch broadband; you need to terminate cable or FiOS, for example, and a WiFi router, which means that you probably have to cover most of the device cost with the baseline features. Adding in firewalls and other elements won’t add much, so removing them to the cloud won’t save much.
The “tenancy” question is even more fundamental. Obviously, something hosted on a customer’s premises isn’t likely to be multi-tenant, and it’s very possible that the focus on vCPE has inadvertently created an NFV fixation on single-tenant VNFs. That’s bad because the great majority of service provider opportunity is probably based on multi-tenant applications.
If you want to host a website, you don’t spin up an Internet to support it. In many cases you don’t even spin up a new server, because the hosting plan for most businesses uses shared-server technology. If you believe in wireless, do you believe that every customer gets their own IMS and EPC? Is 5G network slicing likely to be done on a slice-per-phone basis? IoT presumes shared sensors, virtual or real. Almost everything an OTT offers is multi-tenant, and the operators want to reap the service opportunities that OTTs now get almost exclusively. Might that demand multi-tenant thinking? Thus, might it demand multi-tenant NFV?
There are huge differences between a vCPE application and virtual IMS or EPC. The one that immediately comes to mind is that “deployment” is something that’s done once, not something done every time a contract is renewed. The fact is that multi-tenant VNFs would probably have to be deployed and managed as cloud components rather than through the traditional NFV MANO processes, for the simple reason that the VNFs would look like cloud components.
This raises an important question for the cloud and networking industries, and one even more important for “carrier cloud” because it unites the two. The question is whether NFV should be considered a special case of cloud deployment, or whether NFV is something specific to per-user-per-service vCPE-like deployments. Right now, it’s the latter. We have to look at whether it should or could become the former.
The first step is to ask whether you could deploy a multi-tenant service element using NFV. At the philosophical level this would mean treating the network operator as the “customer” and deploying the multi-tenant elements as part of the operator’s own service. There’s no theoretical reason why the basic NFV processes couldn’t handle that. If we made this first-stage assumption, then we could also presume that lifecycle management steps would serve to scale it or replace faulted components. The key is to ensure that we don’t let the operator’s customers have control over any aspect of shared-tenant element behavior. Again, no big deal; users of a corporate network service wouldn’t have control over that service as a shared-tenant process; the network group would control it.
One fly in the ointment that I came across early on is that many of these advanced shared-tenant features are themselves pieces of a larger application. IMS and EPC go together in 4G networks, for example. If you deploy them independently, which likely you would do since they are separate pieces of the 3GPP mobile infrastructure model, then you’d have to know where one was put so you could integrate it with the other. In the original CloudNFV plan, these kinds of features were called “foundation services” because they deployed for building into multiple missions.
Foundation services are like applications in the cloud. They probably have multiple components and they probably have to be integrated in an access or workflow sense with other applications. The integration process at the minimum would have to support a means of referencing foundation services from other services, including other foundation services. In “normal” NFV, you would expect the service elements to be invisible outside the service; not so here.
This relationship between foundation services and NFV may be at the heart of NFV’s future. Somebody asked me, on my blog yesterday, what the value proposition was for the deployment of cloud elements via NFV. The only possible answer is improved lifecycle management, meaning management across the spectrum of legacy and software-hosted elements. That’s not handled by NFV today, though it should be, and so NFV is not clearly useful in foundation service applications. This, despite people in places like AT&T saying that NFV is fundamental to 5G, means that it’s not clear NFV is needed or even useful there.
You can’t create the future by declaring it, people. If we want NFV to take the next step, then it has to do what’s necessary. We have ample evidence of both the truth of this and the direction that step has to be taken. Is it easier to do nothing? Sure, but “nothing” is what will result.