I’ve been talking all this week about the evolution of NFV as a concept, leading up to the ISG meeting in Malaga next week. One topic that’s been covered is the slippery distinction between “cloud hosting”,“NFV hosting”, or just plain hosting, of something. Some of the ISG use cases, such as IMS, EPC, and even CDN are really inherently multi-tenant service applications that are instantiated and then simply sustained. That’s much more like a cloud application, in my view. So a logical question to ask is “What about other use cases that aren’t multi-tenant?” Turns out they can pose some interesting issues, and we had an announcement yesterday from NetSocket that illustrates that “NFV” can mean a lot of symbiotic things.
The best examples of single-tenant use cases are found in “service chaining”, where features like firewall, DNS, DHCP, load balancing, encryption, and application acceleration are offered as service elements not only per user but also per access point. These services are typically aimed at businesses where the price of the service and the cost of the appliance are higher, and service chaining aims to replace premises boxes by hosted software features linked into a chain of connectivity via NFV. Presumably, as is the case with many early PoCs and trials of this, the virtual functions are hosted in the cloud.
But should they be? NetSocket doesn’t think so, at least not in all cases. They’ve announced the “Virtual Edge”, what the company calls a “MicroCloud Server” that replaces traditional service termination devices with an x86 platform that can host virtual functions just as well as a data center could. The MicroCloud concept aims to provide the same kind of agility in service features, immunity from box change-outs, and COTS hosting that NFV aims to provide overall, but with what might be two important differences—customer specificity and SDN integration.
Edge hosting is a two-edged sword in terms of NFV issues. On the one hand, things hosted in an edge device on the customer premises aren’t using shared resources and so can be managed as discrete devices by both customers and providers. If you have shared infrastructure you have to use policy proxy management (though that’s not yet accepted, it’s true nevertheless). But on the other hand, if virtual functions are spread out more end-to-end, it’s hard to avoid the conclusion that NFV will have to connect and deploy functions across legacy infrastructure and SDN, which extends the management scope to legacy technology. That’s not in-scope to the ISG.
NetSocket proposes to address the connectivity issues in an innovative way that mixes tunnel VPNs and vSwitch technology to configure local connectivity and also manage WAN connections. This makes the entire network connectivity offering into a managed service, and as I’ve noted you have end-to-end surveillance because you’re located on the customer premises so “managed service” can mean just what it says.
The notion of edge-hosting NFV functionality isn’t new. RAD announced what it calls “Distributed NFV” earlier, and Cisco and Juniper both have the ability to host service functions on their edge routers (there are ETSI PoCs involving all three of these vendors). The major difference is the nature of the edge device; with NetSocket you’re creating both SDN and NFV in at least proto-form with a software overlay that’s centrally managed. You can see that this could result in lower real-estate costs at the edge and also potentially offer a range of edge platform combinations (servers and local switching) to fit the requirements of all the sites. How all this will price out—whether MicroCloud will be cheaper than edge boxes with Linux boards—isn’t clear at this early stage, but it seems likely that a server solution would generally offer lower price points. That means that the overall service management efficiency will likely set operator prices and profit levels, getting us back to my point that it’s management practices that make or break NFV overall.
Some sort of hosted managed-service strategy is critical for the SMB space because high labor costs and lost time due to errors and maintenance boost SMB network TCOs to about double that of large enterprises. SMBs are often eager to unload network support and features from local devices to a managed service, and according to my surveys are also the class of business most likely to be looking to add new features, beyond even what they currently host in a traditional way.
Edge-driven agility poses some interesting questions for NFV. An edge device (a server like NetSocket offers or a Linux board inside a traditional network device) could easily host agile service elements and sustain current management practices. If the vendor provides a good central tool for deployment of the agile features, it meets all the basic goals of NFV without requiring a resource pool. One of the strongest value propositions for the edge-driven model of “NFV” for example is the fact that you don’t have to build that resource pool to deploy virtual functions. Every customer gets a MicroCloud server, so costs expand at the same rate that revenue expands. With central hosting you build a pool and hope you can fill it with revenue dollars quickly.
You could base edge-driven NFV on NFV, of course. In fact, you could use edge-driven NFV to launch services, in order to manage first costs, and migrate gradually to a shared resource pool as customer volume or service demands dictate. You could also use the edge-driven model to host virtual functions in areas where customer density is too low to support a resource pool at all. This approach would raise a question, though; do all edge-driven NFV hosting points have to look like virtual data centers, clouds, run on x86 and Linux, or what? Agility at the edge seems smart, but to exploit it you have to have an open framework for coordinating service feature deployment to both central cloud resources and to what might be diverse edge facilities.
We may have to address these questions pretty quickly, too. The tradition of the Internet—bill-and-keep rather than settlement for transport—has essentially killed any hope of end-to-end QoS because you can’t distribute payments for it. If neutrality is dead, then QoS settlement might come along, which would then allow overlay VPNs to provide similar service to the more expensive provisioned VPNs of today. That would favor an edge-driven model of managed services, and would also tend to distribute agile NFV-like functions more to the edge, changing the whole notion of function hosting. Exciting times are ahead, I think.
