In a number of recent blogs I’ve talked about the critical value of intent modeling to NFV. I’d like to extend that notion to the management plane, and show how intent modeling could bridge NFV, network management, and service operations automation into a single (hopefully glorious) whole.
In the network age, management has always had a curious dualism. Network management has always been drawn as a bottom-up evolution from “element” management of single devices, through “network” management of collective device communities, to “service” management as the management of cooperative-device-based experiences. But at the same time, “service” management in the sense of service provider operations, has always started with the service and then dissected it into “customer-” and “resource-facing” components.
The unifying piece to the management puzzle is the device, which has always been the root of whatever you were looking at in terms of a management structure. Wherever you start, management comes down to controlling the functional elements of the network. Except that virtualization removes “devices” and replaces them with distributed collections of functions.
The thing is, a virtual device (no matter how complicated it is functionally) is a black box that replicates the real device it was modeled on. If you look at a network of virtual devices “from the top” of the management stack (including from the service operations side) you’d really want to see the management properties of the functionality, not the implementation. From the bottom where your responsibility is to dispatch a tech to fix something, you’d need to see the physical stuff.
This picture illustrates the dichotomy of virtualization management. You still have top-and-bottom management stack orientation, but they don’t meet cleanly because the resource view and the service view converge not on something real but rather on something abstract.
If we visualize our virtual device as an intent model, it has all the familiar properties. It has functionality, it has ports, and it has an SLA manifest in a MIB collection of variables. You could assemble a set of intent-modeled virtual devices into a network and you could then expect to manage it from the top as you’d managed before. From the bottom, you’d have the problem of real resources that used to be invisible pieces of a device now being open, connected, service elements. The virtual device is then really a black box with a service inside.
Might there be a better way of visualizing networks made up of virtual devices? Well, one property of a black box is that you can’t see inside it. Why then couldn’t you define “black boxes” representing arbitrary useful functional pieces that had nothing to do with real network devices at all? After all, if you’re virtualizing everything inside a black box, why not virtualize a community of functions rather than the functions individually?
This gives rise to a new structure for networks. We have services which divide into “features”. These features divide into “behaviors” that represent cooperative activities of real resources, and they divide into the real resources. In effect, what this would do is to create a very service-centric view of “services”, meaning a functional view rather than one based on how resources are assembled. The task of assembling resources goes to the bottom of the stack. All composition is functional, and when you’ve decomposed your composition to deploy it, you enter the structural domain at the last minute.
This approach leads to a different view of management, because if you assemble intent models to do something you have to have intent-model SLAs to manage against, but they have to be related somehow to those black-box elements inside them. To see how this could work, let’s start by drawing a block that’s an intent model for Service X. Alongside it, we have one of those cute printer-listing graphics that represents the MIB variables that define the intent model’s behavior—what it presents to an outside management interface.
But where do they come from? From subordinate intent models. We can visualize Services A and B “below” Service X, meaning that they are decomposed from it. The variables for Services A and B must then be available to Service X for use in deriving its own variables. We might have a notion that Service X Availability equals Service A Availability plus Service B Availability (simplified example, I realize!) That means that if Services A and B are also black boxes that contain either lower-level intent models or real resources, the SLA variables for these services are then derived from their subordinate elements.
This notion of service composition would be something like virtual-device composition except that you don’t really try to map to devices but to aspects of services. It’s more operations-friendly because that’s what you sell to customers. I would argue that in the world of virtualization, it’s also more resource-management friendly because the relationship between resource state (as reflected in its variables) and service state (where it’s reflected) is explicit.
How would you compose a service? From intent models, meaning from objects representing functions. These objects would have “ports”, variables/SLAs, and functionality. The variables could include parameter values and policies that could be set for the model, and those would then propagate downward to eventually reach the realizing resources. Any set of intent models that had the same outside properties would be equivalent, so operators could define “VPN” in terms of multiple implementation approaches and substitute any such model where VPN is used. You could also decompose variably based on policies passed down, so a VPN realized in a city without virtualization could realize on legacy infrastructure.
In this approach, interoperability and interworking is at the intent model level. Any vendor who could provide the implementation of an intent model could provide the resources to realize it, so the intent-model market could be highly competitive. Management of any intent model is always the same because the variables of that model are the same no matter how it’s realized.
The key to making this work is “specificational” in nature. First, you have to define a set of intent models that represent functionally useful service components. We have many such today, but operators could define more on their own or through standards bodies. Second, you have to enforce a variable-name convention for each model, and create an active expression that relates the variables of a model to the variables generated by its subordinates (or internal structure). This cannot be allowed to go further than an adjacent model because it’s too difficult to prevent brittle structures or consistency problems when you dive many layers down to grab a variable. Each black box sees only the black boxes directly inside it; the deeper ones are opaque as they should be.
Now you can see how management works. Any object/intent model can be examined like a virtual device. The active expressions linking superior and subordinate models can be traversed upward to find impact or downward to find faults. It it’s considered useful, it would be possible to standardize the SLAs/MIBs of certain intent models and even standardize active flows that represent management relationships. All of that could facilitate plug-and-play distribution of capabilities, and even federation among operators.
We may actually be heading in this direction. Both the SDN and NFV communities are increasingly accepting of intent models, and an organized description of such a model would IMHO have to include both the notion of an SLA/MIB structure and the active data flows I’ve described. It’s a question of how long it might take. If we could get to this point quickly we could solve both service and network management issues with SDN and NFV and secure the service agility and operations efficiency benefits that operators want. Some vendors are close to implementing something like this, too. It will be interesting to see if they jump out to claim a leading position even before standards groups get around to formalizing things. There’s a lot at stake for everyone.