One of the key pieces of network functions virtualization (NFV) is the “virtual infrastructure manager” or VIM. In the E2E ETSI model for NFV, the VIM takes instructions from the management and orchestration element (MANO) and translates them to infrastructure management and control processes. One of the challenges for NFV implementation is just what shape these instructions take and just how much “orchestration” is actually done in MANO versus in the VIM. To understand the challenges, we have to look at the broader issue of how services as abstractions are translated to infrastructure.
A service, in a lifecycle sense, is a cooperative behavior set impressed on infrastructure through some management interface or interfaces. Thus, a service is itself an abstraction, but the tendency for decades has been to view services as a layer of abstractions, the higher being more general than the lower. Almost everything we see today in service lifecycle management or service automation is based on an abstraction model.
The original concept probably came from the OSI management standards, which established a hierarchy of element, network, and service management. It’s pretty clear that the structure was intended to abstract the notion of “service” and define it as being a set of behaviors that were first decomposed to network/administrative subsets, and finally down to devices. This was the approach used by almost all router and Ethernet vendors from the ‘90s onward.
If we presume that there’s a service like “VPN” it’s not hard to see how that service could be first decomposed by the administrative (management) domains that were needed to cover the scope of the service, and then down to the elements/devices involved. Thus, we could even say that “decomposition” is an old concept (even if it might have gotten forgotten along the way to new developments).
The Telemanagement Forum (TMF) largely followed this model, which became known as “MTNM” for Multi-Technology Network Management. An implicit assumption in both the old service/network/element hierarchy and the MTNM concept was that the service was a native behavior of the underlying networks/devices. You just had to coerce cooperation. What changed the game considerably was the almost-parallel developments of SDN and NFV.
SDN networks don’t really have an intrinsic service behavior that can be amalgamated upward to create retail offerings. A white-box switch without forwarding policy control sits there and eats packets. NFV networks require that features be created by deploying and connecting software pieces. Thus, the “service behaviors” needed can’t be coerced from devices, they have to be explicitly created/deployed. This is the step that leads to the abstract concept of an “infrastructure manager”.
Which is what we should really call an NFV VIM. All infrastructure isn’t virtual; obviously today most is legacy devices that could still be managed and service-coordinated the old way. Even in the future it’s likely that a big piece of networks will have inherent behavior that’s managed by the old models. So an “IM” is a VIM that doesn’t expect everything to be virtual, meaning that on activation it might either simply command something through a legacy management interface or deploy and connect a bunch of features. In SDN, an IM is the OpenFlow controller, and in particular those infamous northbound interfaces (NBIs).
It’s comforting, perhaps, to be able to place the pieces of modern network deployment and management into a model that can also be reconciled to the past. However, we can’t get cocky here. We still have issues.
I can abstract a single management interface, at a low level. I can abstract a high-level interface. The difference is that if I do abstraction at a low level, then I have to be able to compose the service myself, and issue low-level commands as needed to fulfill what I’ve composed. If I can abstract at a high level, I have the classic “do-job” command—I can simply tell a complex system to do what I want. In that case, though, I leave the complexity of composition, optimization, orchestration, or whatever you’d like to call it, to that system.
This is a natural approach to take in the relationship between modern services and OSS/BSS systems. Generally, service billing and operations management at the CRM level depend on functional elements, meaning services and meaningful, billable, components. Since billable elements are also a convenient administrative breakdown, this approach maps to the legacy model of network management fairly well. However, as noted, this supposes that there’s a sophisticated service modeling and lifecycle management process that lives below the OSS/BSS.
That’s not necessarily a bad thing, because we’ve had a pretty hard separation between network management and operations and service management and operations for decades. However, having two ships-in-the-night operations processes running in parallel can create major issues of coordination in a highly agile environment. I’m not saying that the approach can’t work, because I think it can. I am saying that you have to co-evolve OSS/BSS and NMS to make it work through a virtualization transition in infrastructure.
The thing that seems essential is the notion of a service plane separate from the resource plane. This separation acknowledges the way operators have organized themselves (CIOs run the former, and COOs the latter), and it also acknowledges the fact that services are compositions built from resource behaviors. The infrastructure has a set of domains, a geographic distribution, and a set of technical capabilities. These are framed into resource-level offerings (which I’ve called “behaviors” to separate them from the “service” elements), and the behaviors are composed in an upward hierarchy to the services that are sold.
Infrastructure managers, then, should be exporters of those “behaviors”. You should, in your approach to service modeling, be able to ask an IM for a behavior, and have it divide the request across multiple management domains. You should also be able to call for a specific management domain in the request. In short, we need to generalize the IM concept even more than we’re working to generalize it today, to allow for everything from “do-job” requests for global services to “do-this-specifically” requests for an abstract feature from a single domain.
But we can’t dive below that. The basic notion of intent modeling demands that we always keep a functional face on our service components. Behaviors are functional. Service components are functional. In the resource domain, they are decomposed into implementations.
I do think that the modeling approach to both service and resource domains should be the same. Everything should be event-driven because that is clearly where the cloud is going, and if service providers are going to build services based on compute-hosted features, they’re darn sure not going to invent their own architecture to do the hosting and succeed. The cloud revolution is happening and operators first and foremost need to tap it. Infrastructure management and controller concepts have to be part of that tapping.