The world of SDN and NFV is always interesting, like a developing news story filled with little side channels and some major scoops. One of the latter just came from RAD, whose “distributed NFV” raises what I think are some very interesting points about the evolution of the network.
The traditional picture of NFV is that it would replace existing network appliances/devices with hosted functions. Most presume that this hosting will be done on general-purpose servers, and in fact that’s what the White Paper that launched NFV actually says. Most also believe that the hosting will take place in operator data centers, and most likely will. But RAD’s announcement demonstrates that there’s more to it.
The details of RAD’s story aren’t out yet; they’re scheduled to be released in New York at the Ethernet and SDN expo in early October. What RAD is saying now is that their vision is based on the simple principle that “Ideally, virtualized functions should be located where they will be both most effective and least expensive, which means NFV should have the option to return to the customer site.” That means hosting at least some virtual functions on-premises or at least at the carrier edge, and that in turn might well mean taking a broader look at NFV.
There’s always been a tension between the operationally optimum place to put a network feature and the traffic-and-equipment optimality. Operationally, you’d like everything to be stacked up in a common space where techs can float about getting things fixed. However, some functions in the network—application acceleration is an example—rely on the presumption that you’re improving performance by conserving access capacity. To do that, you have to be upstream of access paths, meaning on the customer premises. You can always exempt this kind of technology from NFV, but it makes sense to think about whether an edge device might not have some local hosting capability, and might thus serve as a platform for part of NFV deployments. That seems to be the sense behind RAD’s “distributed NFV” concept, and I agree with the notion.
That’s not the end of the NFV extension issue, though. I’ve said many times that there are a number of highly credible situations where shifting from custom appliances/devices to servers and hosting doesn’t make sense. As you move downward through OSI layers you flee features and encounter only aggregated multi-user streams. What’s the value of software agility there, at say the optical layer? Further, can we expect server technology to spin optical bits around as effectively as a custom device? I don’t think so. Even deeper electrical products like switches and routers may demand higher availability because they’re still aggregation devices not access devices. You can’t make a data path resilient through redundancy unless you want to stripe data across multiple routes, which I think raises costs more than NFV principles could cut them. Thus, we’re going to have things that are outside NFV but that stay inside the network.
Deploying a virtual network function inside “the cloud” is a function of cloud management APIs. You could extend Nova implementations in OpenStack to handle device-hosting of virtual functions, or even simply use Linux cards to create what looks like a server inside a device. You can also create an alternative “Service Model Handler” (to use our CloudNFV term) to deploy edge functionality using whatever mechanisms are required. What changes is the question of deployment complexity. The more we distribute virtual functions, the more likely it is that there are places where one could be put that would be, for the service situation being presented, seriously sub-optimal. In some cases, in fact, it’s likely that the virtual function being deployed would be specialized for the edge equipment and couldn’t be hosted elsewhere. That fact has to be communicated to the NFV implementation, or there will be multiple parallel strategies for deploying functional components of service logic. All we need to ruin a cost-savings and agility-building strategy is multiple incompatible and parallel approaches.
A similar issue arises with non-virtualized functions, meaning native or persisting devices. If we presumed universal transfer of network functionality from devices to hosting, we could presume cloud principles and software logic would define management practices. Virtual service components could be managed as application components. But if we have real devices, do we then force virtual components to be managed as virtual devices, or do we create two tracks of management—one mostly conventional EMS/NMS and the other software-hosted management—and hope to somehow reconcile them? How do we even define a service that embodies both virtual components and real devices?
The point here is that it’s going to be hard to contain NFV. Some of its impacts are going to spread out to involve things that the original mandate never included, simply because the original mandate of commercial servers won’t optimally support the full range of network service models. I don’t think that would surprise the founders of NFV, but it might surprise the vendors who are looking to build NFV support. In particular, it might surprise those who are looking at the area of “NFV management”.
Why? Because there can’t be any such thing. You manage services, you manage resources. That’s what network management is, and must be. There can be only one management model or management isn’t effective. I believe that the management evolution of NFV, an evolution that’s likely to evolve from the liaison between the NFV ISG and the TMF, is the most important element in the success of NFV in the long term. It’s also the most important element in the continuing relevance of the TMF and OSS/BSS concepts. This is a test, folks. Virtualization, fully implemented, would let us define virtual function management any way we like. It cannot be fully implemented, so we have to harmonize in some way—without losing the cost efficiencies and agility that NFV promised from the first. Can that happen? I think it can, but I don’t think that every NFV implementation will support this vision. That means it’s going to be important to look for that support as implementations emerge.