A Somewhat-New Approach to VNFs

Most of you know that I like the concept of a VNF platform as a service (VNFPaaS) as a mechanism for facilitating onboarding and expanding the pace of NFV deployment.  That’s still true today, but I had some recent conversations with big network operators, and they tell me that it’s just not in the cards.  The time it would take to redirect industry efforts along those lines is too great; NFV would be obsolete by the time the steps were taken.  They did have an alternative that I think has merit; the notion of supporting a series of cloud PaaS frameworks as coequal VNFPaaS models.  There may even be a sign of commercial (vendor) interest in that approach.

The NFV specifications don’t define a specific hosting environment for VNFs.  Presumptively, they are deployed on a VM with a complete set of supporting platform software (operating system and middleware) bundled with them.  There are also minimal definitions to establish how a VNF in such a framework would link to the rest of the NFV management and orchestration structure.  This combination generates a lot of variability, and that means that prepping VNFs for deployment is hardly a standard process.  VNFPaaS would declare a single framework for deployment and execution, one that could provide a single set of APIs to which VNFs could be written.  Obviously, that would facilitate the onboarding and use of VNFs, but whose framework would the VNFPaaS be?  That question can’t be answered in a world where consensus has to be reached for progress, and when consensus means competitive trade-offs by all those involved.

The “multi-VNFPaaS” approach says that while software development takes place on multiple platforms, there are a small number that dominate.  One example is Java, which is supported on nearly all the hardware out there.  Suppose, instead of trying to get everyone to agree on one platform, we took the group of popular ones and prepped a VNFPaaS for each?  Staying with the Java example, we could define a specific set of Classes that represented the extensions to basic Java needed to make VNFs work with the central NFV processes.  You could have cooperative efforts define these platform-specific VNFPaaSs or you could let the platform’s owners do the heavy lifting to qualify their stuff.

Operators might prefer having full portability of VNFs across platforms, but that’s not in the cards.  They say that because most software is written to one single platform, it would be difficult to port software from one platform to another.  Basic service APIs wouldn’t line up.  Today, for example, we’re still working on a perfect solution for porting between Java and Microsoft’s .NET, even though we have more than a decade of experience.  Thus, while it might seem that we’d be giving up portability by accepting multiple VNFPaaSs, the truth is that probably wasn’t a realistic option anyway.

Even if we accept the notion of multiple platforms for VNFPaaS, there’s still the question of coming up with those Classes or APIs that provide the links between the VNFs and NFV.  We end up with a set of “basic service APIs” that access operating system and middleware services and that are outside the VNFPaaS scope, and another set of APIs that have to connect to the NFV foundation or core services and infrastructure.  This other set of APIs should be “adapters” that convert a convenient API structure for the platform involved to whatever API is used by the NFV core implementation.

Which is?  We really need to have some specific API here, which means that we really need to have a specific structure in mind for the VNF management process (VNFM).  There is a presumption in the current specs that VNFM has two pieces, one that is co-resident with the VNF and the other that is centralized and shared.  Leaving aside for the moment just how functionality is divided among these and what the specific APIs are for each, making this approach work in a multi-platform VNFPaaS would be a matter of the implementation of the API within the platform.  You could envision a platform that took responsibility for all VNFs using a remote service, one that left everything to a local process embedded in the VNF, one that used a local service bound to the VNF, or any combination of these.

What has to be standardized in this case is the relationship between the VNF-bound VNFM and the central VNFM.  It wouldn’t be too hard to do that if we had a complete picture of what a VNF deployment looked like in terms of network address space and components, but we really don’t have that as yet.  What could be done without it?  Well, the problem is that unless we assume that every NFV implementation exposes a common central VNFM API, we’re stuck with customization of the platform’s management APIs to match the APIs of the core NFV software.  That would mean that VNFs wouldn’t be fully portable within a given platform, because different NFV MANO/VNFM implementations might use different APIs.

The good news in this area is that we have a number of activities working on streamlining the onboarding of VNFs.  The specific details of these are difficult to obtain because most of the initiatives haven’t produced public output, but since it’s hard to see how you could automate a service lifecycle without any standard interfaces to work with, they should at least expose the issues.  That would probably be a useful step in solving the problems.

The reason for the “probably” qualifier is that we’re still not thinking systemically about the problem of service lifecycle management.  There are multiple management models—the “resource management only” approach that says you just keep things working as planned and it will all work out, through the “service-driven” approach that says all problems are detected at the service layer and remediation is driven from the top.  Which are we talking about?  There are issues of the network model for NFV—you have services and customers who might be “tenants” and have to be kept separate at one level, yet in most cases will resolve onto the Internet address space together.  You also have your own NFV control processes, which have to be isolated from tenants, and yet have to provide them services.  Till all of this stuff is laid out, it’s going to be difficult to apply the lessons of onboarding VNFs to the broader problem of service lifecycle management.

I don’t want to put on rose-colored glasses here, though.  Facilitating VNF onboarding removes a barrier to VNF deployment, but a removed barrier is significant to a driver only if they are on a journey where the barrier is encountered.  We still have major issues with making a broad business case for NFV.  My view that such a business case demands addressing service lifecycle management and its automation hasn’t changed.  Some of the new initiatives on onboarding could also expose issues and opportunities for lifecycle management overall, and this could be instrumental in proving (or disproving) whether operations efficiencies are enough to drive NFV forward.