I’ve talked a lot about the importance of NFV to the industry at large, and about the fact that management/orchestration (MANO) is the heart of NFV. As the term itself suggests, MANO is the fusion of two interdependent processes that also happen to be phases in a service lifecycle. To most involved in NFV, the deployment of services using or based on NFV is a process of orchestration, and once the deployment is underway or complete (depending on your view), it’s up to management to take over. This dualism is interesting because it impacts both where NFV has to go in a functional sense, and what specific case studies or proofs of concept are most relevant.
Let’s look for a moment at three “NFV services”. One is the mobile/LTE service that consists largely of IMS and Evolved Packet Core (EPC) functionality. The second is an enterprise branch access service-chaining application, and the final one is a multi-featured cloud-based collaborative relationship. All of these have been suggested by someone as a target for NFV, but they’re all very different in how they balance the “MAN” and the “O” in MANO. We’ll start with deployment and move through lifecycle stages to see what the differences in these services can tell us.
Our mobile/LTE service is going to be deployed when mobile LTE is offered in a geography, and once it’s deployed it will remain in place as long as LTE is sold. Yes, there will likely be in-service changes and repairs and so forth, but you don’t deploy IMS with each call. In fact, mobile/LTE is inherently a multi-tenant service. Deployment or orchestration, our “O” in MANO, isn’t something that happens very often. It’s also something that isn’t exactly extemporaneous; operators plan for years for cellular deployments. In fact, you could install the service components manually, and orchestration is valuable only to the extent that the functionality is exercised as part of scaling, problem response, etc.
With our enterprise branch access application, the service is instantiated when the customer orders it, and it stays in place for the life of the contract—a year or two, perhaps, or more. It’s possible that the service might be sold as “Branch-OnRamp-To-VPN”, in which case it might be sold each time a new branch comes online. “O” is a little bigger here, more likely to happen. Our branch service is also inherently single-tenant, which means that we have to instantiate it for every customer rather than once for all customers as we did with mobile/LTE. We also have to pay a little attention to the provisioning delays, but because branches don’t spring up like weeds it’s not likely that the service would demand instant response to an order. Finally, we need to think about the fact that some of the service orders might be fulfilled by hosting part of the functionality in a local device, some by remote hosting, and some even by just sending a custom box as before. That’s complicated .Orchestration is valuable here because it automates a task that’s going to be repeated pretty often and be variable in details, meaning it could be messed up often if it weren’t systematized. Also, labor costs for manual operation could be pretty significant.
Now we come to our collaborative application. Here we have a function that’s likely to be deployed for a period of hours or minutes, and is also inherently single-tenant. Depending on where the participants happen to be, the range of facilities that might be required and the optimum location for features to be hosted could be highly variable. We might even need ad hoc multi-provider federation of resources. Given those parameters we simply can’t expect to offer the service at a price buyers would pay unless we can do something about the amount of manual activity and costs, and reduce the time it takes for the service to be rolled out when requested.
Let’s now look at sustaining the service during its active state, clearly part of the “MAN” in MANO. Again, we’ll explore the three services separately.
Our mobile/LTE service is going to be a major user of resources, resources committed to the service for the long haul because the service is essentially perpetual. Just as we could orchestrate the service deployment manually, we could make management connections manually. It’s also true that IMS/EPC works on the presumption that you manage collective resources to achieve a grade of service for calls, not that you manage every call. Thus, “service management” is really not a major issue here. What we do have to worry about is whether the resources used for this service are shared with other services so that we’d have to be aware of the boundaries. In most cases, IMS/EPC is likely to have dedicated resources, so management isn’t much changed here.
With our branch access device service, we have a number of complications. First, service management has to be considered distinct because the buyer of the service is going to expect to manage the logical or functional device, whether we elect to send a box or build part of the functionality by assembling VNFs in a chain. We see the first real management issues with this example, then. Second, the hosting point for the VNFs associated with this service could be local in an agile edge device, distributed into a server farm somewhere, or both. The resources used in distributed hosting are almost certain to be shared. This introduces a second management issue, which is isolating shared resources from interference created when one user of the resource attempts to exercise what the user thinks is normal service management. These two factors combine to suggest that management functions will need to be virtualized in parallel with service elements in NFV. Otherwise we can’t compose the two and insure they are harmonious through the management lifecycle.
How about our third application, collaboration? Here we see an interesting dynamic because as the application becomes more pervasive, it moves from looking somewhat like a short-cycle branch-access service deployment (specialized resources per user/instance) to looking like a multi-tenant service based on shared resources, like our mobile/LTE application. If we had a large and active group of collaborative users, we’d certainly provision the service like any shared service. For a small specialized group, we’d handle it like a one-off.
What we learn from this is that the thing that matters the most in NFV isn’t the application itself, it’s the dynamism and scale of the application. It’s whether “service management” is seen as a specific need or not, whether virtualization impacts what’s visible to the service buyer, not just impacts the service. If we want to get the most from NFV, we should be testing the agility and dynamism of proposed services and measuring their effect on both “MAN” and “O”. Otherwise we risk running tests and demonstrations that don’t move the ball.