You can't pick up an NFV presentation or document without seeing a diagram of an early NFV model that looks like a collection of virtual boxes and virtual links. This model is a classic example of most of the early thinking about the NFV which is a key element of New IP architecture. However, the problem with this early model is that it's too specific.
Changing for the better
I built models as a kid, as many kids do. I was never a master of dexterity and mine often ended up being something quite different from what I (or the company who designed the kit) intended. The same thing is happening in the case of NFV models -- sometimes called a "service chain" or "forwarding graph." The people standardizing network functions virtualization (NFV) also need to build models and there are signs that their early conception of an NFV model is changing. The good news is that it's changing for the better, and here's why.
First, let's consider a situation where NFV is deployed as a substitute for a single appliance. The service chain represents the functions of that appliance, but the description of what's needed is specific to the NFV's implementation. Intuitively, an NFV version of a box and the legacy, physical box should look the same at one level of modeling, and differ only when you dive down to how you're going to deploy it. That way, service orders could order features without regard for whether they happened to be NFV-supported or legacy-based.
The second example is that different vendors might collect and connect functions for our virtual box in different ways: maybe Vendor A has three elements in a service chain, and Vendor B has two, four or five. If the virtual boxes perform the same way within the service should they not be modeled the same way at the service level, and differences in vendor configuration be reflected only somewhere below?
The impact of these two example seems to have been brought to a head by the opening of an NFV work item on the relationship between software-defined networking (SDN) and NFV. In SDN, by design, the controller is responsible for setting up routes by aligning the forwarding rules of a series of devices. You don't specify the route from the outside, so the "forwarding graph" of SDN should not be specified by (or even be visible to) the NFV element that requested the connection.
Finding an alternative
So what's the alternative? For literally decades, it's been common to describe software as a series of objects that were effectively "black boxes." A black box presents its features on the outside, but you can't see inside. In black-box terms, an NFV virtual function isn't a service chain or forwarding graph, it's simply a description of its features and its service level agreement (SLA).
There's a more modern and elegant term for this, which is "intent model," a major step forward in NFV.
An intent model describes the intent of a function, but not how that intent is realized. Anything that can create the specific external behaviors described in the model is a suitable and equivalent implementation.
One nice thing about intent models is that they explicitly specify their management properties -- and that requirement is a big step forward in defining how NFV management would work. You can't have functionality without specification of the SLA, or range of conditions in which it can be delivered. If you describe an NFV service through an intent model, you define an SLA for it and then you define how that modeled object should appear to a management system. What's inside or below, the implementation, now has to populate the specified management model.
Interchangeability is another important difference with intent models because an operator can use any set of virtual functions and real devices that implement an intent model to substitute for any other set. The use of intent models separates functional modeling of services -- which is what a service architect would likely do -- with the deployment of resources to fulfill the functional requirements. Vendors could package intent-model solutions that would be interoperable, and most important managed in the same way.
Plug and play
There are two places in NFV where intent models seem perfect. One is at the high level, where a service is presented for deployment. The input to NFV management and orchestration (MANO) should be an intent model, and MANO should then determine the "recipe" it will use to fulfill the intent. Similarly, virtual infrastructure managers (VIMs) should receive intent models that describe a deployment or connection.
In a management sense, all the implementations of an intent model should expose the same management interfaces and variables and accept the same parameters from above. That makes all the implementations fully plug-and-play. NFV's management specifications could then focus on how to populate intent-model management variables from the real management information bases (MIBs) below, and how to pass parameters from the intent-model level into the resource assignments that implement the model.
If we do intent modeling right in NFV, we can address a lot of critical issues and at the same time focus future work on constructive paths. It's not clear yet whether the European Telecommunications Standards Institute (ETSI) NFV Industry Specification Group (ISG) is committed to this approach, but it seems to have strong support and that's a very good sign.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp., special to The New IP