Summary Bullets:
- Despite the VNFM becoming better defined, the question of who is best placed to supply it remains an open issue.
- Vendors are taking different approaches to VNFM development; they will need to be harmonized if carriers are to realize multi-vendor NFV MANO.
While the work of the ETSI Steering Group on NFV management and orchestration (MANO) has never been a secret, the draft specification (GS NFV-MAN 001 V0.6.1) just published throws up some interesting questions.
There are three major building blocks in a MANO solution: the NFV orchestrator (NFVO), the virtual network function manager (VNFM) and the virtualized infrastructure manager (VIM). As the NFV initiative has developed over the past several years, the focus of attention in NFV management has shifted perceptibly. Initially, the VIM (e.g., OpenStack, VMware, etc.) at the bottom of the stack was the issue; then, the special requirements and complexities of telco network orchestration kicked in and attention shifted up to the NFVO at the top. Now, it’s the turn of the VNFM, which – notwithstanding the awesome responsibilities of the NFVO – is the “bit in the middle” that often turns out to be the most contentious.
Put very simply, the VNFM is responsible for the lifecycle management of the VNF under the control of the NFVO, which it achieves by instructing the VIM. However, this is the big question: who is best placed to supply the VNFM? As the ETSI architecture shows, the VNFM has strong “all-round” affinities, with the VNF itself, the VIM and the NFVO.
This leads to some very interesting differentiation between various companies’ MANO propositions. The default position, and the one adopted by the likes of Alcatel-Lucent’s CloudBand Management System and Ericsson’s Cloud Manager, is to make the VNFM part and parcel of their overall solution, i.e., closely aligned with the NFVO. That said, Nokia’s Cloud Application Manager appears to be closer to being a discrete VNFM product. On the other hand, Oracle Communications’ recently announced Application Orchestrator is most definitely a VNFM (it has yet to reveal an NFVO), but has been promoted in close association with the company’s virtualized IMS core VNFs. Going even further, HP’s NFV Director, which spans both NFVO and VNFM realms, not only claims to support “external” VNFMs, but intriguingly, through its own “embedded” VNFM, also offers to “provide the VNF manager functionality… [to] compensate for completely or partially missing VNF manager functionality in the vendor solution.” That’s pretty much covering all the bases. However, we’re not finished yet. Coming in from below, Wind River, a platform supplier to many network equipment suppliers, has recently extended its Carrier Grade Communications Server architecture (an NFVI/VIM platform) up the MANO stack to include VNFM functionality.
So, all in all, the VNFM is attracting a lot of interest from all directions, and while the ETSI standards are not yet “set in stone” and neither are the aforementioned companies’ MANO strategies and products, there is certainly a debate to be had. Is the mark of a good VNF supplier one that also provides its own VNFM? Is the mark of a good MANO supplier one that can accommodate a VNF without a VNFM? Is the mark of a good NFVI platform vendor one that takes away the need for a VNF supplier to even develop a VNFM? There are likely many more angles to explore around the VNFM, but from an operator’s perspective, they will certainly need to be harmonized or multi-vendor NFV implementations may well get “stuck in the MANO.”