Every month we have a year's worth of changes in networking, it seems. When the latest development, Network Functions Virtualization, emerged as a carrier initiative, the response of one Wall Street research firm was to generate a new report called "NFV, As If We Needed Another Acronym". It does seem like we're making more progress brewing alphabet soup in networking these days than in driving change, but there are some very big and important players behind NFV and it's worth looking at how it might impact network services and even unified communications.
Operators don't like the custom-device approach because they see it as a way for network vendors to pick their pockets with proprietary strategies. It follows that they wouldn't be all that happy if an NFV architecture allowed every vendor to build their own version of every virtual function and make sure their stuff wouldn't work with anyone else's. Thus, the operators are looking at a framework where functions would be interoperable, which would imply having standard APIs for each function type so a buyer could mix and match.
What even this high-level vision creates is a double-barreled risk to current network paradigms, and vendors. All network devices are differentiated by either price or features, and to sustain feature differentiation you need to have new features to add, features that are driven by buyer interest. NFV's cloud-hosting of features moves them out of network devices, and an open set of feature APIs would let anyone build features and link them to anyone's hardware, making it harder for equipment vendors to differentiate even their own cloud-hosted versions.
At the infrastructure level, NFV's adoption would require that there be cloud elements available to host virtual functions close to devices in those cases where the response time of a service might be influenced by network delay. That means that you could expect to see operators deploying cloud resources all the way out to carrier central offices and maybe even to some cell sites.
There are about 10,000 COs in the US and perhaps a quarter-million major cell sites. Imagine how many cloud data centers would be created if you had to put some virtual function hosting points in them all. It would be the biggest driver of data center network change in the industry. Connect them all to create a cloud and you'd have the biggest cloud application that ever was. No wonder everyone is trying to figure out what this future network would look like.
The service side of this picture is also interesting. If NFV makes everything except actual packet forwarding a virtual function, and if Software Defined Networking (SDN) centralizes the control of packet forwarding to facilitate software control, then the network equipment is a puppet on the software world's strings. Everything we'd think about in networking, from security to QoS and management, would be a software function, and every one would need to have one of those open APIs that operators want. We could spawn a cottage industry writing virtual functions, not unlike the industry created for developers with the iPhone and Android app stores.
In this kind of world, you could build services that mixed elements of what we think of today as completely independent functions. UC features could draw on network APIs to create collaboration connections, but standard calls could also draw on UC features and turn into collaborative relationships among the parties. We'd have a host of new solutions, an explosion of service innovation, and we'd scare the pants off the incumbents in all of the network-related service and equipment spaces.
Many enterprise communications and collaboration services today are essentially linked with devices, in that they're offered as a locally hosted package, including UC/UCC. Many of the vendors are already making accommodations to a service-driven future for UC/UCC even without direct NFV impact, too. Cisco's decision to make WebEx users full participants in telepresence meetings is an example of the need to fuse populist collaboration with specialized collaboration, and you can expect to see the same features coming from premises-based communications and collaboration tools as well. Some are going to see this as a major threat to UC.
It could be a major boon, too. The more divided enterprise and even consumer communications becomes, the more value there is in creating unity for a given worker/user. What we gain is an enormous paint box from which we can draw our colors. What we lose is any notion that there's a single product with a single mission. In the network of the future, everyone gets to be an artist, not just a painting-buyer. That makes the question of composing a communications framework, the selection not only of a GUI but also of a set of policies that bind components and select features as needed, the most important one in the communications services world.
It's a question that's not answered now, not by UC vendors or others. We're still thinking of appliances at our fingertips, things with fixed functionality, even as the network evolves to support complete functional virtualization and flexibility. Will Apple or Google catch on to the opportunity here, or perhaps Microsoft or Avaya? NFV concepts will mature over the course of this year, and we may know by 2014 what the future network services world, as well as the future network infrastructure, will look like.
Follow Tom Nolle on Google+!
Tom Nolle on Google+
