The Management and Orchestration (MANO) stack in the ETSI NFV model is a place full of interesting, and confusing at times, ideas. Many vendors have very different ways of looking at the functionality provided in that area. For reference, below is the standard ETSI NFV framework, with some of the underlying and surrounding components added:
One of the best defined areas within MANO, and most mature, is the Virtual Infrastructure Manager (VIM) component. As such we won’t spend a lot of time on that. OpenStack is the clear leader in this area for NFV use cases, with VMware being the major player in the IT Cloud space. Regardless of vendor chosen it is a must that you have strong management of the Compute, Storage, and Networking resources available. Whether you are using VMware, with NSX, or OpenStack, with vanilla Neutron, OpenContrail, OpenDaylight or another option, the network controller space is pretty well defined too.
The next level up, VNF Manager, is an evolving area as new vendors appear with VNF offerings that include a vendor specific manager. Some of the major vendors are working on VNF Managers to be THE manager, such as Cisco and their Elastic Services Controller. The key thing to remember here is any management environment built needs to be able to support multiple VNF Managers. Due to the many emerging VNF vendors it is probably also a good practice to leverage the VNF Managers supplied by each vendor instead of trying to shoehorn all management into a single VNF Manager.
The functionality you should expect to get out of the VNF Manager(s) boils down to full lifecycle management of the VNFs under its control. This includes orchestration activities with the VIM to obtain resources to place a VNF on, installation and provisioning of the VNF on those resources, and then monitoring of the performance of a VNF over time. The VNF Manager should see when a VNF becomes overloaded and spin up additional instances to load balance across in order to resolve the issue. Thresholds should be able to be set to prevent the VNF Manager from spinning up unlimited instances of a VNF. Additionally, if the load lessens, it should be possible to scale back the instances to free up resources for other use. Lastly, the VNF Manager plays a part in the self-healing nature of the cloud. It should be possible to spin up a replacement instance, move the workload to that fresh instance, and then tear down the troubled VNF.
The top level of the MANO stack is one where things are pretty wide open at the moment. There are players from the traditional OSS space, emerging vendors with a more cloud-focused pedigree, and even open source alternatives, such as the OpenStack Murano project, attempting to provide THE solution here. One key thing to remember is that there are two layers of orchestration involved. One is the end to end orchestration, which lives above the MANO stack and includes communication with traditional OSS/BSS systems such as Billing, Provisioning, Ordering, etc. The other is pure play cloud orchestration.
To properly provide cloud orchestration there are two key areas to cover, Service Orchestration and Resource Orchestration. There is some argument that Resource Orchestration and the management of NFVI Resources really belongs to the VIM, or that NFVI Resource Management should become a fourth level unto itself in the MANO stack. Regardless of your views on this, it is important that an orchestration layer somewhere north of the VIM and VNF Manager(s) have a view of cloud resources that is exposed via API to northbound systems as needed.
Cloud Service Orchestration is another key area, with a few sub-components that are worth mentioning. The Network Services Catalog contains descriptors (think templates) for the various Network Services provided by the NFV environment. Likewise, the VNF Catalog contains VNF descriptors. The Cloud Orchestrator utilizes these catalogs, and integration with the VNF Manager(s), to expose capabilities of the NFV environment to higher level systems. The resulting Cloud Services are stored in the NFV Instances repository, giving a de facto inventory of NFV based services that have been provisioned.
Now, should you be worried if your vendor doesn’t have a box that fits in all of the above layers? Should it be warning sign if your vendor is a traditional OSS vendor trying to enter this new space, meaning their tools shouldn’t be reaching out of their bounds and into the cloud? No and No. The framework above is intended to be just that. A guideline for you to follow, not a blueprint for your implementation. There are vendors that are working on end to end orchestration products that are very capable of reaching down into the MANO stack and providing functions in that area, especially with regard to the Cloud Orchestration component. There are also vendors that play in the VIM layer that have full capability to reach up into higher levels of MANO to provide some of those functions.
The important thing to remember is you must cover the functions above to have a successful NFV deployment. Whether that is one tool to rule them all, or a set of 5-6, or more, tools integrated to provide what you need for YOUR specific use cases is something you have to go find out. It is all about knowing what you need, planning accordingly, vetting out the top 2-3 vendors that play in those areas, and then implementing with confidence that you are going to be successful. There are no shortcuts to a successful NFV deployment, and no shortcuts/easy answers to the MANO need.
Tags: Network Management