A piece of good news on the NFV front is that the ETSI ISG is moving toward consideration of intent modeling as the basis for a number of important interfaces. I’ve been advocating intent modeling for several years now, so obviously I’m pleased with the move. You should be too, and everyone else in both the SDN and NFV spaces, because the decision if implemented could have significant short- and long-term benefits.
In some prior blogs, I’ve suggested that both SDN and NFV must be framed around the concept of “network as a service” or NaaS. NaaS is an abstraction of a connection service, such that it can be realized using any suitable technology or combination of technologies. A VLAN or VPN should be a NaaS abstraction.
The reason for this is that operations evolution has to lead technology/infrastructure evolution. You can’t have customers or customer service agents looking at a service order to decide what technology will have to be used to fulfill it. Services have to be ordered in terms of what they deliver, and that must then be translated into how it gets delivered. An abstract VLAN can be ordered as a VLAN and built using any combination of legacy, SDN, and NFV.
The key to making this work is the abstraction itself, the representation of NaaS. The abstraction of a connection service has to describe the connection in terms of endpoint behaviors and service-level agreements (SLAs). Think of it as a “description” of the service (the logical topology, which in the case of a VLAN is a “multipoint” service, and its QoS attributes, for example) and a list of endpoints.
This sort of model has been known in the industry for some time (I’ve referenced it in a blog or two earlier). It’s called an intent model because it models not how something is done but what the “something” looks like to its consumer. There have even been papers describing the application of intent modeling to virtual networks. However, intent modeling was not a part of the original ETSI conception of NFV, though it was the foundation of both my CloudNFV and ExperiaSphere work.
It’s fair to ask where exactly intent modeling might fit inside the ISG’s end-to-end model, and there are a number of places. Let’s start at the top.
A “service” is first and foremost an intent model, as my example here illustrates. Buyers don’t expect a blueprint and a heap of parts, they want a car. Service models should be viewed at the top as perhaps a cascade of intent models, each representing a commercial chunk of the service, presented by features and not by implementation. This could be modeled as the TMF’s “Customer-Facing Services” or CFSs.
The challenge of intent models is that you eventually have to deliver on the intent, which means that you have to be able to decompose the “intent” into realization at the resource level. The easiest way to visualize this is to think about a point in your service cascade where the structure below ceases to be intent-based and becomes resource-based. In the TMF world this could be described as the boundary between Customer-Facing and “Resource-Facing Services” or RFSs.
It’s difficult to say with confidence where this boundary point is in the ETSI ISG world because they’ve put operations out of scope. Instead, let’s shift focus for a moment and look at the ETSI structure to see where intent models might fit.
One obvious place is the top. A request for VNF deployment should never be expressed in the form of resource-specific recipes because you don’t know where a given service would optimally locate its components (likely dependent on service locations, for example). So the input to NFV MANO from the OSS/BSS (the Os/Ma Interface in the E2E model) should be an intent model, perhaps what we could call a “deployment order” to distinguish it from what’s above.
In fact, all of the interfaces that ETSI draws “inside” the MANO block of the E2E model should likely be visualized as intent models because in all of them you have an abstraction of behaviors on one side and realizations of the behaviors on the other. However, the most important place for intent modeling besides the input to MANO is the VNFM-to-VIM connection (the Vi-Vnfm Interface if you’re keeping score). This is where the service model’s realization has to be converted into specific hosting and connection processes, which means that network connectivity and NaaS are “below” the VIM (which you’ll recall I tend to generalize as Infrastructure Manager to reflect the fact that some of the infrastructure in a real service isn’t virtual at all).
In a general case, then, NFV could be considered to be a description of the boundary between CFSs and RFSs in TMF terms. The input to NFV is a CFS representing an intent model decomposed from the original retail service (it might be that service if there are no commercial components, or it might be a commercial chunk thereof). The VIM’s output has to be resource-specific, which says it’s a part of the “cascade” of resource models.
This raises what’s likely the critical intent-model-related question in NFV today, which is just where inside NFV the CSF-RFS boundary occurs. If I feed CFS models into the top and get resource controls out the bottom, then we can infer that “orchestration” in general is the boundary function between the two. But what does the border-crossing? It’s either a MANO function or a (V)IM function.
I think it depends on how resource choices are made. IMHO, a “service” can set policies within its intent model that would guide resource selection, meaning that a service could require things that preference one implementation over another. It should never make selections itself because that would mean you’d have to retroject resource knowledge into service models. If a (V)IM is a representative of, an abstraction of, resources, then unless you want there to be one logical VIM, you have to assume that RFS modeling takes place above it, with the VIM at the bottom of the tree where models turn into actual resource commitments.
I think this same approach is the way that federation of multiple providers or even SDN domains should be handled. Each “domain” is associated with a resource model that can commit the infrastructure within. This part of the model is (V)IM-related. Above the (V)IM is a model that describes how services are decomposed by domain. You could then visualize a (V)IM not as a piece of logic but rather as a set of models, which says that pretty much the whole of NFV can be visualized as an intent model and the decomposition of that model.
Which is where I think NFV should go ASAP. Accepting some approach like this would help focus the ISG on the specific things required to make NFV work as part of a service process, and that’s the way it has to work if it’s going to deliver service management efficiency or service agility.