I think that most of my readers realize by now that I think the data modeling associated with NFV is absolutely critical for its success. Sadly, few of the players involved in NFV say much about their approach to the models, and I’ve not been able to get the same level of detail from all of those I’ve asked. I do think it’s possible to make some general comments on the modeling approaches of the few vendors who have credentials in making an NFV business case, and so I’ll do that here. To do this, I’ll introduce the key points of an NFV data model and then talk about how vendors appear to address them. If I cover your own approach in a way you think is incorrect, provide me documentation to support your position and I’ll review it.
The first aspect of a data model is genesis. All of the NFV models stem from something, and while the source doesn’t dictate the results, it shapes how far the approach can get and how fast. The primary model sources are TMF SID, cloud/TOSCA, and that inevitable category, other.
Alcatel-Lucent and Oracle appear to have adopted the TMF SID approach to NFV modeling. This model is widely implemented and has plenty of capabilities, but the extent to which the detailed features of the model are actually incorporated in someone’s implementation is both variable and difficult to determine. For example, the TMF project to introduce Service Oriented Architecture (SOA) principles, GB942, is fairly rare in actual deployments, yet it is critical in modeling the relationship between events and processes.
HP is, as far as I can determine, the only announced NFV player who uses the cloud/TOSCA approach. That’s surprising given the fact that NFV deployment is most like cloud deployment, and the TOSCA model defined by OASIS is an international standard. IBM uses it for its own cloud orchestrator architecture, for example. I think TOSCA is the leading-edge approach to NFV modeling, but it does have to be extended a bit to be made workable for defining legacy-equipment-based network services.
In the “other” category we have Overture, who uses the open-source distributed graph modeling architecture, Titan. This is an interesting approach because Titan is all about relationships and structural pictures thereof, rather than being tied to a specific network or cloud activity. It’s probably the most extensible of all the approaches.
The second aspect of the data model is catalogability, to coin a term. To make an NFV model work, you have to be able to define a service catalog of pieces, assemble these into service templates, and then instantiate the templates into contracts when somebody orders something. All of the models described by the key NFV vendors have this capability, but those based on the TMF SID have the most historicity in supporting this approach, since SID is the model long used by OSS/BSS systems and vendors.
Both HP and Overture have the ability to define models of substructures of a service and assemble them. Either of the approaches appear to be suitable, but they lack the long deployment history of SID and the integration of operations processes with these non-SID models has to be addressed explicitly since there’s no TMF underlayment to appeal to for features integration with operations. HP also provides for inheritance from base objects, and they appear to be alone in modeling resource structures as well as service structures. I think SID models might be able to do that, but I can’t find an example in the material for our TMF-based vendors.
The third aspect of the data model is process integration. In order to synchronize and support efficient network and service management, you somehow have to link NFV to NMS and OSS/BSS processes. There are two basic ways to do that—one being the virtual device approach and the other what I’ll call the explicit event steering approach. Details on how vendors do this stuff is extremely sparse, so I can’t be as definitive as I’d like.
It appears that both Alcatel-Lucent and Oracle have adopted the virtual-device approach. NFV sits at the bottom of a resource structure defined in the SID, and operations and management processes couple to SID as usual. The goal of NFV deployment implicitly is to make the deployed elements look like a virtual device which can then be managed as usual. In theory, the GB942 event coupling to SOA interfaces via the SID is available, but I’ve got no details on whether it is implemented by either vendor. Since GB942 implementation is rare, the answer is “probably not”. This combination means that service automation steps “inside” VNFs is probably managed totally by VNF Managers, and may be opaque to OSS/BSS/NMS. I can’t be sure.
HP’s approach seems also to rely on VNFMs for lifecycle processes at the NFV level, but they have a general capability to link events to processes through what they call a monitor in their SiteScope management component. You can establish monitor handlers, transgression handlers, trigger handlers, etc. It would appear to me that this could be used to integrate lifecycle processes within NFV to larger management and operations domains, though I don’t have an example of that being done.
Overture has the clearest definition of process integration. They employ a GB942-ish mechanism that uses a business process language and service bus to steer events generated by their management analytics layer, or another source, to the correct operations/management processes. The approach seems clear and extensible.
The next area to consider is management data integration. To me, the baseline requirement for this is the establishing of a management repository where status information from resources and services is collected. Everyone seems to do that, with Alcatel-Lucent and HP integrating their management data with their own platforms, and Overture using a system that unites open-source NoSQL, Cassandra, and Titan. In theory all these approaches could generate management data correctly, and I believe that both HP and Overture could present custom management of modeled service elements. On the rest, I don’t have the data to form a clear view.
The final point is support for modeled legacy elements. In HP this capability is explicit in the modeling, and HP is the only player that I can say that for. HP’s data model incorporates legacy components explicitly so you can define service solutions in a mixture of legacy and SDN terms. Since HP’s NFV Director is derived from their legacy control product line, it has full capabilities to control legacy devices. HP can also operate through OpenStack and ODL.
With Alcatel-Lucent and Oracle, modeling legacy elements is implicit in their SID basis, meaning that their processes are really legacy processes into which NFV is introduced so there’s little question legacy networking could be accommodated. Under the virtual devices that NFV represents, both support OpenStack and ODL.
Overture can support legacy devices in a number of ways. First, the Titan model is technology-agnostic so there’s no data model issue. The model can drive a control-layer technology set to actually deploy and connect resources using legacy or NFV (or SDN) technologies. Overture has their own network controller that (obviously) supports their own equipment and can be augmented through plugins to support third-party elements. They can also work through OpenStack and ODL to support legacy devices that have suitable plugins for either of those environments.
The data models used for services are, as I’ve said, the most important thing about how a vendor implements NFV, and yet we don’t talk about them at all. Public material on these models is limited for all the vendors I’ve listed. What would be great would be an example of a service modeled in their architecture, containing both VNFs and legacy elements, and linked to NMS and operations processes. If any of these four vendors (or anyone else) wants to send me such a picture for open use and publication then I’d love to see it and I’d almost surely blog on it.
What can we learn about NFV from this? Well, if the most important thing about NFV is something nobody is talking about and few have any support for at all, we’re not exactly in the happy place. There is no way you could do a responsible analysis of NFV implementations without addressing the points I’ve outlined here, which means without defining an explicit data model to describe services and resources. If you see an analysis without these points (whether from a vendor, the media, or an analyst) it’s incomplete, period. I hope my comments here will help improve coverage on this important topic!