Just after yesterday’s Overture Networks announcement on an NFV platform, we now hear from Light Reading that Edgewater Networks has launched a project to develop an SDN/NFV position. Today, we also had a revised submission of the CloudNFV Proof-of-Concept to the ETSI NFV ISG. Alcatel-Lucent has been promoting its SDN and NFV position on the anniversary of its Nuage acquisition, and I’m told by operators that they are getting (as one described it) a “new round of NFV promotion” from vendors. NFV has been hype-hot for some time, but might it be getting hot for real now, and if so, why?
I’ve noted for some time that the great majority of “NFV” solutions we see these days are really simply pieces of a foundation on which NFV might run, or things that might run on it. Having a server doesn’t make you a cloud provider, so I think it’s fair to say that what we have listened to for the most part has been exploiting NFV interest rather than developing NFV capability. The major network vendors have not really promoted a full and open NFV approach, according to the operators I’ve surveyed (some now tell me that vendors are shifting a bit to be more open, though). The point here is that operators need NFV to be something very specific because they need it to present specific benefits and play a specific role. There’s a lot of open ground in real NFV implementation, which could become high ground in a tactical sense if NFV really takes off.
NFV infrastructure is where a lot of the NFV announcement focus has been, but at the basic level NFV infrastructure isn’t a big issue. It’s mandatory that any complete NFV solution be able to deploy and operationalize virtual functions on any commercially available server/cloud platform, and also accommodate special platforms like edge devices. The OpenStack model, which uses plugins for deployment of machine images on VMs and also for the control of network resources, could be adapted to accommodate much of the hardware out there. If you add in some generic mechanism for handling legacy elements of the network, you have pretty much what you need.
The Virtual Network Functions (VNFs) themselves are a bigger issue. The most logical source of a VNF is the pool of open-source network components out there, which some estimate to number in the thousands, perhaps as many as ten thousand. To leverage everything available, you have to be able to on-board VNFs without modification, which means that management and orchestration features of NFV have to be applied to VNFs without special APIs. Overture made a point of stating that as one of their fundamental goals (it was also a fundamental goal for CloudNFV) so there may now be some direct pressure on “NFV vendors” to address whether their approach is truly VNF-accommodating.
There’s a kind of an interesting blur-point here that we can now note. If there is “VNF-accommodating” capability built into an NFV implementation, then it has to be accommodated from an architecture perspective. Where is the stuff that manages the VNFs living, software-wise? Keep the question in mind.
MANO, or management and orchestration, is the big black hole of NFV. Everybody wants to talk “orchestration” but what most talk about when they mention their capabilities is one or both of two things we’ve had all along. Thing One is OpenStack’s Nova and Neutron deployment and connection APIs. These are great tools but they’re an example of structural orchestration because they are designed to provide for multi-vendor implementation of a set of cloud service models. They don’t provide generalized network configuration control and they don’t integrate management. Thing Two is “service chaining”, which for most means simple stitching of paths between VNFs using SDN or even a legacy technology. Yes, you have to connect virtual functions into cooperative communities to use them, but that’s not NFV in and of itself because you can’t accommodate management nor generalize service creation by stitching. What we need to make NFV into NFV is functional orchestration.
Functional orchestration lets us create services (retail services) by assembling predefined components, all of which are at their roots the structurally orchestrated service models created by the NFV Infrastructure. Functional orchestration includes the ability to co-compose deployment topologies and management derivations so you can manage the functional assemblies (including “virtual devices” like a virtual branch access device) from the user or customer-service side, and then manage real assigned resources from the network operations side.
Overture’s announcement included a service modeling approach that allowed for the creation of functional assemblies, even though Overture doesn’t position themselves as the high-level orchestrator. It would be fairly easy for them to integrate this with OSS/BSS, but clearly they see themselves as being more an enhanced structural orchestrator than a functional orchestrator. That means that there’s an opening for functional orchestration that startups or incumbents could fill. Thus, we can say that the boundary between “functional” and “structural” orchestration is somewhat elastic. You could push the boundary higher and delegate more orchestration to “infrastructure managers” or you could push the boundary lower and let operations-linked tools dive downward right to the edge of the real network control and hosting APIs. Or anything in between. That’s the kind of open range that new market entrants love.
There’s also a question of whether NFV orchestration has its own set of APIs, making it something like a PaaS platform. We can’t make it a requirement for VNFs to use these APIs without ruining our open-VNF mandate, but we could allow optimization, analytics, and other stuff to be openly linked to a basic ecosystemic NFV PaaS, and even expose (with great care) optional tools to facilitate integration with NMS/NOC and OSS/BSS processes. You could build a kind of substrate of NFV PaaS to facilitate VNF development too, and improve service agility at the functional level.
I’m kind of excited about what this might all mean. Could we be finally moving to the NFV market phase were something actually useful emerges? Could we be on the verge of exposing, and addressing, the real issues that should have been there all along? If so, that would be great for us all.