Most people would agree that NFV crosses over a lot of subtle technology boundaries. It’s clearly something that could (and IMHO likely would in most cases) be hosted in the cloud. It’s something that is certain to consume SDN if there’s any appreciable SDN deployment, and it’s something whose principles of orchestration and management are likely to slop over into the broad (meaning legacy device) network.
The orchestration and management implications of NFV are particularly important, in part because we don’t have a fully articulated strategy for orchestration of services today and we don’t really have a handle on management of virtual, as-a-service, or cloud-based resources. There have been some announcements of element/network management systems that incorporate orchestration principles; Amartus, Overture Networks, and Transition Networks all have management platforms that are converging functionally on a holistic model for management and orchestration. What’s not yet clear is how far all these players will go and how long it will take to get there.
NFV presumes virtual network functions (VNFs) deployed on servers (in the cloud, or in some other way) will be linked to create cooperative functional subsystems that can then be composed into services. This process is a deploy-connect model that has to be carried out in a systematic way so that all the pieces that have to participate are there somewhere and are mutually addressable. This is very much like cloud application deployment, so much so that a number of the current NFV implementations (CloudBand and CloudNFV) use cloud technology to support the actual deploy-connect process (orchestration decides what to deploy and connect, and where, so it’s still a higher-level function).
The complication is that a realistic service consists of a bunch of elements that are probably not VNFs. The access network, metro aggregation, optical transport, and other network elements are either not immediate NFV targets or not suitable for server support at all. There are also likely to be legacy devices in networks that have to be used during a transition to NFV, even where such a transition will be complete eventually. That means that the orchestration process has to handle not only virtual functions but legacy devices.
There are two basic models for implementing orchestration. One is to say that you’ll orchestrate in the same way that you manage, meaning that there would be a series of element/network management systems that would organize service resources within their own domains, and the other is that there’s a master-orchestrator that will take a complete service description and a complete network/resource map, and then place everything and connect it.
Vendors have tended to support the first of these models, in no small part because NFV as a standard focuses on orchestration of VNFs, which leaves the orchestration of legacy components to existing management systems. What’s not clear at this point is what the implications of this situation would be at the service management level.
The TMF and OSS/BSS vendors have generally worked to create service templates that describe how a service would be put together. These templates model the service, but not necessarily at the level needed to create a complete recipe for optimized deployment. Certainly it’s likely that these templates would need to be updated to hold the information necessary to deploy VNFs, unless it was possible to define each element of the model of a service as being targeted at a single specific NMS/EMS that could “sub-orchestrate” the deployment of that element. Even there, the question is whether that sort of decision could be made atomically; would it not be true that the optimum placement of VNFs depends on the way the rest of the service, the legacy part, is supported?
Another issue is that orchestration is where resources are assigned to service mission fulfillment. You can’t do management in a meaningful way without an understanding of the mission (meaning the service) and the state of the resources. Since orchestration sets the relationship, it’s the logical place to set the management processes into place. The optimum management vision for a network that has to be extensively orchestrated for any reason is one that recognizes both the need to create service-relevant management and resource-relevant management at the same time, in a multi-tenant way, and at full network scale. If everyone is orchestrating their heart out at a low NMS/EMS level, how do you provide cohesive management? That problem occurs even today in multi-vendor networks. Imagine it in a network whose “devices” are a mixture of real and virtual, and where the MIBs that describe a real device reflect variables that don’t even exist on servers or in data centers!
My personal view has always been that the TMF models can handle this. You can define service and resource models using the SID (GB922) specification, and the principles of GB942 contract-arbitrated management (where management flows through contract-defined orchestration commitments to find the real resources) seem to resolve many of the management problems. But even here, the question is whether there’s a way to aggregate NMS/EMS-level orchestration to create a unified service model, without creating some higher-level orchestration process to do it.
SDN presents similar issues. It’s likely for a number of reasons that SDN will deploy in a series of “domains”, encompassing a data center here or there and perhaps some metro functionality in between. Maybe in some cases there will even be SDN in branch locations. The management of SDN has to change because it’s not possible to look at a device and derive much information about the service model as a whole; that knowledge is centralized. Yet the central knowledge of what was commanded to happen doesn’t equate to the state of the devices—if it always did, you’d not need to manage anything.
So what we’re seeing here is that the two networking revolutions of the current age—SDN and NFV—both demand a different model of management and orchestration. What model is that? We’re going to need to answer that question pretty quickly, and while current orchestration offerings by vendors may aim too much at the NMS/EMS level, they’re a useful start.