- Convincing carriers that their VNFs are as good as their PNFs calls for a variety of approaches from the vendor community.
- VNF messaging approaches range from “battle-hardened” functionality to “cloud-inside” architectures; however pitched, it’s important to get it out soon.
As NFV gradually moves the industry from physical network functions (PNFs) to virtual network functions (VNFs), application vendors face choices regarding how to position themselves in this new world. As ever, a market transition like NFV will mean that there will be winners and losers. Laying aside all the NFV supporting pieces, such as infrastructure, management and orchestration, etc., what sorts of messaging are application vendors adopting to ensure that their VNFs are at least equally successful, or even more successful, than their PNFs?
- “Battle-Hardened” Functionality
The first market message, put out principally by the major telecom equipment manufacturers (TEMs), is around the accumulated years of operational experience built into VNFs by virtue of their long PNF heritage on ATCA hardware. After all, no one wants a VNF which is either functionality inferior to the PNF or one that, through the virtualization process, resets the network experience “counter” to zero. This approach is frequently termed the “best-of-breed” argument.
- “Platform-Independent” Software
The card played by the early “software telco” proponents such as Metaswitch and other VoIP pioneers is around applications being designed from the start to be hardware platform independent. This means, in effect, that although the application functionality appeared first as PNFs on ATCA, they were (and are) very easy to port to COTS IT platform environments. This sort of messaging is often used to counter concerns around IT versus ATCA platform performance.
- “Cloud-Inside” Architecture
The latest messaging variant is the “cloud-inside” architecture, first coined by Italtel in launching a new session border controller (SBC) last year. The Italtel NetMatch-S SBC can be delivered as conventional PNF, but with a cloud-based SBC VNF and hypervisor infrastructure ready-built “inside.” This means that the SBC VNF can be broken out into a shared cloud infrastructure when the carrier is ready. This could be called a “Trojan horse” approach, but in a benign sense.
Now to be fair, vendors wisely do not stick rigidly to a single messaging thread, but the above is representative of the spectrum of approaches in the market today. Different types of carriers and different organizations within carriers will feel more comfortable with some approaches, rather than others. For example, network operations will likely veer towards “battle-hardened” VNFs, while IT architects will likely favor the software and cloud-based architectural approaches. Whatever the messaging, it is likely to resonate with someone in the carrier organization, so getting it right is very important, particularly if that “someone” is the one holding the purse strings.
And in case vendors think that tuning their VNF messaging can be done when “all the PoCs are finished,” beware: the word on the street is that advanced carriers are already well into their VNF procurement cycles.