There is an inescapable conclusion to be drawn from recent industry announcements: Vendors have lost control of SDN and NFV, which means they’ve lost control of the evolution of networking. Operators, in a state of self-described frustration with their vendors’ support for transformation goals, have taken matters into their own hands. I’ve gotten emails over the last ten days from strategists and sales types in the vendor community, and they’re all asking the same question, which is “What now?” It’s a good question in one sense, and it’s too late to ask it in another—or at least too late to have the full set of choices on the table. But there are always paths forward, some better than others, so we need to look at them.
In a prior blog I made the point that commoditization of connection services was inevitable, and that it was also inevitable that operators will spend less on capital equipment at L2/L3 than they have in the past. Accepting this truth, I’ve said, is critical to vendors who have historically depended on these layers for their revenue and profits.
The up-front truth for this blog is that it is no longer possible for vendors to control the SDN and NFV revolution even if they were to step up now and do what should have been done all along. I’ve noted what should have been done many times and in any case, it’s too late to do it. Buyers have taken their own path now, and vendors need to fit into the operators’ programs and not try to define their own. I’m not saying they don’t need to pay attention to the focus on opex, to the need to develop a holistic SDN/NFV business case, only that doing that won’t give them control of the game anymore.
The key to accommodating operator initiatives seems to start with sophisticated service modeling. All SDN and NFV modeling and the associated APIs and orchestration is derived from the software concept of “DevOps” that defined a way of describing deployment of software elements and their connection into systems we’d call applications. There have always been two models of DevOps, one that describes the steps to take (called the “prescriptive”) and the other that describes the end-state desired (initially called the “declarative” but increasingly called the “intent model”). The critical first step vendors need to take in modeling is to adopt declarative/intent modeling.
“How-to” modeling cannot be general—it has to be a process description that naturally depends on what you’re doing and where you’re doing it. If you describe a system of VNFs in terms of its intent, you can deploy it on any convenient platform. If you say how to deploy it, you can deploy only on the target upon which your instructions were based. All the emerging operator architectures make it clear that a wide variety of platforms, including legacy “physical network functions” or PNFs, have to be supported for any feature. The thing, as they say, speaks for itself (for Latin/legal fans, “res ipsa loquitur”).
I personally think an intent model approach would be ideal across the board, meaning everywhere from top to bottom in an implementation. However, it is essential only at certain key points in the structure of an SDN/NFV package:
- At the top, where SDN/NFV software interfaces with current OSS/BSS systems.
- Underneath “End-to-End Orchestration” or EEO, to define the way that infrastructure-based behaviors are collected into functional units.
- At the “Infrastructure Manager” boundary, to describe how a given behavior is actually deployed and managed for one or more of its hosting options.
Each of these points represent a hand-off that operators are insisting be open, which means that the implementation below has to be represented to the implementation above. Intent modeling makes that mutual representation practical.
The second point that vendors have to enforce in their implementation is the notion of a VNF PaaS implementation. All of the APIs that a VNF presents as an interface have to be connected with a logical paired function, and all of the SDN/NFV and management APIs that a VNF would be expected to use have to be offered in a uniform way to the “virtual space” in which VNFs run. This same requirement exists in a slightly different form for SDN, but in my view it would be met by the support of an intent-model “above” the SDN controller.
This is going to be the most important issue for NFV, I think. Absent a PaaS-like framework, there is no meaningful portability/onboarding, and no way to contain integration cost and risk. Commercial VNF vendors are likely to tie up with NFV partners (as they have already) and integrate only with these partners, which opens a risk of each setting licensing terms that operators will find offensive because there’s little or no competition. Open-source could be totally excluded from the picture.
A “VNF” is a system, a black box that provides a feature or features, asserts an explicit SLA, and contains a range of deployment options that could adapt to conditions by scaling or replacement. All of this good stuff should happen inside the box, with specific contained APIs to link the functionality with the rest of the service ecosystem. Absent that, we have no reliable integration, and we are absent that now.
The next point is perhaps the largest problem, and a problem that would have to be solved in order to solve the VNFPaaS challenge. Management, meaning lifecycle management at all levels, has to be defined explicitly or nothing can be integrated at all—no VNFs, no NFVI, nothing. The current model is kind of like the software equivalent of the universal constant (“That number which, when multiplied by my answer, yields the correct answer.”) We have the VNF Manager that might be integrated with each VNF, or it might be centralized, or a combination of both. What is integrated with a VNF is part of a tenant-service, and what is centralized is part of the management system. You can’t float between these two environments because it’s not secure or reliable to do so, any more than you can let applications change the operating system.
The really big problem here is that the industry approached all this from the bottom, and you can’t really do management right except from the top. You manage services against the SLA. You manage service components against the behavior that you set for them to secure the SLA, and you manage resources to the standards required to make those component-level behaviors work. Management should be linked to modeling, so that every model layer has appropriate SLAs and management definitions. That way you have management of the system of functions that make up a service, down to the system of resources that support the functions.
The final point for SDN/NFV vendors is to focus strongly on federation, not only across operator boundaries but across implementations of SDN and NFV at the lower level. “Federation” in my context means supporting an autonomous implementation at some level by representing it as an opaque model to the level above.
A good modeling approach will take you a long way toward federation support of this sort because an intent model makes the “who” and “how” opaque to the higher-level orchestration process. However, there are a number of commercial relationships possible among operators, and there’s always going to be a number of different approaches to sharing management data.
Accommodating the commercial relationship is an implementation issue with intent modeling. The decomposition of a model representing a federated lower-level (or partner) element just means activating whatever that lower-level process might be, at any appropriate level. So you could have a “treaty federation” where billing data didn’t have to be exchanged, or one where the order process in one domain was activated by the orchestration in another.
The management stuff could be more complicated, depending on how good the management model is to start with. If you presume my preferred approach, which is a repository in which all “raw” management data is collected and from which management APIs present query interfaces, then there’s no real issue in controlling what a partner sees or how it should be interpreted.
In some respects, operator architectures could make it easier on vendors. If they fit in the architecture they don’t have to offer a complete solution. If they fit in the architecture they don’t have to sell the entire SDN/NFV ecosystem. It could create focused procurements and shorter sales cycles. It certainly will facilitate more limited service-specific applications of SDN and NFV, as long as they can be fit into the operator’s holistic model. It’s also surely an indication that the SDN/NFV space is maturing, moving from media hype to the real world. It’s just important to remember that doesn’t mean media hype becomes the real world. Operator architectures are the proof of that.