An important question in the NFV space is also a simple and obvious one; “What is a good VNF?” This question is something like the rather plaintive question asked early in the NFV evolution; “Where do I start?” and it’s a close relative to the “What do I do next?” question that many vCPE pioneers are already asking. Most of all, it’s related to the key sales question “Who do I get it from?”
A virtual function is something ranging from a piece of a feature to a set of features, packaged for unified deployment. As far as I’ve been able to tell, all the VNFs so far offered are things that have been available for some time in the form of an appliance, a software app, or both. Many of them are already offered in open-source form too. Given all of this, it’s not a surprise that there’s already a conflict in pricing, as operators complain that VNF vendors are asking too much in licensing fees. That’s simply a proof point that you can’t do the same thing in a better way unless that means a cheaper way.
In the consumer market today, the licensing fees for VNFs are probably indefensible across the board. The consumer’s needs for the standard vCPE-type VNFs are basic, they can buy an appliance for less than 50 bucks that fulfills them all, and some CPE is necessary for consumer applications because you need in-home WiFi. Even for enterprises, a half-dozen big network operators have told me that they can’t offer enterprises virtual function equivalents of security and connectivity appliances at much of a savings versus the appliances themselves. Managed service providers who add professional services to the mix have done best with the vCPE VNFs so far.
Addressing the licensing terms is critical for VNF providers and also for NFV vendors who’ve created their own ecosystems. The operators report two issues, and sometimes a given VNF provider has both of them. The first is a very steep first tier price, often tied to minimum quantities. This forces the operator to surrender a lot of their incentive to use hosted VNFs in the first place; they don’t have a favorable first-cost picture. The second problem is lack of any option to buy the license for unlimited use at a reasonable price. VNF providers say this is because an operator could end up getting a windfall; the problem is that the alternative to that can’t be that the VNF vendor gets one.
Licensing challenges like this are killing both residential and SMB VNF opportunity, slowly but surely. They’re also hurting NFV deployment where it’s dependent on vCPE applications. Operators have been outspoken at conferences and in interviews that something has to be done here, but perhaps the VNF providers think they have the operators at a disadvantage. They don’t.
A technical approach to reducing the licensing issues would be supporting multi-tenant VNFs. The problem with vCPE in particular is that the cost of licensing has to be added to the resource costs for hosting. The smaller the user, the lower the likely revenue from that user, and the less tolerable it is to host that user’s functions on independent VMs. Even containers won’t lower the cost enough to get to the mass-market opportunity. VNF providers, though, are reluctant to provide multi-tenant solutions, perhaps again because they see dollar signs.
Progress in this area is almost certainly going to come too late. For VNFs that represent basic security and connectivity, I don’t think the market will live up to expectations. Operators have no incentive to work hard to sell something that’s only marginally profitable to them, and VNF software companies don’t want to let go of the notion that somehow this is their brass ring. There is already a ton of good open-source stuff out there, and I think that there’s a lot of impetus developing from operators to make it even better. In fact, I think that we’re long overdue in launching some initiative to figure out how to facilitate open-source ports of functionality to VNF form in an organized way, what I’ve called VNF Platform as a Service or VNFPaaS.
A good VNFPaaS approach could help non-open-source approaches, particularly those who want to sell premium data services to businesses. The Internet is becoming the cost-preferred approach for private network building, and the evolution of SD-WAN could radically accelerate that trend. If we were to see overlay VPNs/VLANs take over in terms of connection services, then any OTT provider could build in all the security, connectivity, and other useful features that the market could desire. If that even starts to happen the high velocity of the OTT players could make it impossible for operators to catch up.
We’ll get VNFPaaS eventually, and when we do, open source will eat the enterprise VNF security/connectivity space. So what about VNFs in other areas?
The most promising area for VNFs is also the most difficult for most vendors to address. Mobile use of NFV is almost a slam dunk, which means that everything related to RAN, IMS, and EPC will eventually be turned into virtual functions. The challenge is that the vendors with the inside track in this area are the vendors who already supply RAN, IMS, and EPC or who have compelling demonstrations of their experience and credibility. There aren’t many of these.
In theory, it would be possible to create “vCPE-like” VNF opportunities for mobile users. Obviously not by hosting at the point of connection, on a per-user basis, though. Could IMS or EPC be equipped with hooks for mobile-user security? Surely, but this has not been so far a populist opportunity either. What operators should be asking for is a VNFPaaS interface with IMS/EPC so that they could use their (multi-tenant, fairly priced) VNFs with mobile infrastructure.
This could be of critical importance for broader opportunity realization because of the whole IoT-and-contextual services thing. Even the currently dominant IMS/EPC players are at risk down the line if they fail to support embedded services to facilitate these two opportunity areas. While data path security is a fair lock for the operators today, as we noted earlier it is feasible that shifting to Internet-based overlay VPN/VLANs could kill that edge. For the mobile space, the “personal agent” model could do the same, because if a user is really communicating directly only with a personal agent, then whoever owns that agent can provide all the network features the user would see (and buy).
The notion of a VNFPaaS is obviously critical to the success of VNF vendors because without it the relationship between VNFs and the rest of the NFV process isn’t standardized enough to support agile development and wide-ranging features. The ETSI specifications, which in fairness were not (at least originally) supposed to define an implementation, are not sufficient to insure the VNF ecosystem can evolve. Vendor strategies, even open ones, are likely to differ among vendors, particularly if large vendors see a chance to create a lock-in because they have a favored VNF that will pull through their approach. This issue should be a priority with the ETSI ISG because nobody else is likely to take it up.
NFV demands a different vision of networking if it’s to succeed on a large scale. VNF providers and operators alike are trying to drive their own revenue models without much regard for the other stakeholders in the game. However, everyone in the VNF space has to understand that the operator is not compelled to migrate to NFV, and that sellers who insist that buyers accept unfavorable profit balances rarely prosper themselves. It’s going to take time and effort to get all this shaken out, and accommodations on the VNF side are in my view inevitable.