Sridhar Rao
Sridhar received his Ph.D degree in computer science from National University of Singapore, in 2007; M.Tech. Degree in computer science from KREC, Suratkal, India, in 2000; and B.E. degree in instrumentation and electronics from SIT, Tumkur, Bangalore University, India, in August 1997. He worked as Associate General Manager at NEC Technologies India; Research lead at SRM Research Institute, India; Post-doctoral fellow at Microsoft Innovation Center, Politecnico Di Torino, Turin, Italy; and as a research fellow at Institute for Infocomm Research (I2R) Singapore. He has worked on various development and deployment projects involving ZigBee, WiFi and WiMax. Sridhar is currently working as Solutions Architect as Spirent Communications India Limited.
Defined in ETSI ISG NFV architecture, MANO (Management and Network Orchestration) is a layer ― a combination of multiple functional entities ― that manages and orchestrates the cloud infrastructure, resources and services. It is comprised of, mainly, three different entities ― NFV Orchestrator, VNF Manager and Virtual Infrastructure Manager (VIM). The figure below highlights the MANO part of the ETSI NFV architecture.
NFV Orchestrator is responsible for managing the functions such as network service life-cycle management and the overall resource management. Service management or orchestration deals with the creation and end-to-end management of the services ― made possible by composing different virtual network functions (VNFs). Resource management helps in ensuring that the NFV-infrastructure resources are abstracted cleanly (independent of VIM) to support the services that access these resources.
The VNF Manager oversees the lifecycle (typically involves provisioning, scaling, terminating) management of instances of virtual network function (VNF). It is typically assumed that each VNF will be associated with a VNFM that will manage that particular VNF’s lifecycle. A VNFM may manage multiple instances of the same type of VNF or different types of VNFs.
The Virtualized Infrastructure Manager (VIM), controls and manages the NFVI compute, storage, and network resources. This is the most critical component of NFV-MANO, and it is not surprising that it has received themost attention from the industry.
In summary, when MANO is seen as a single entity, the typical functionalities of include (a) Infrastructure automation and providing consistent, accurate and global view of the resources, (b) Network integration, (c) VNF lifecycle management and its placement in in NFVI, (d) service management, (e) Performance monitoring, analysis and governance (auditing, compliance) support.
The VIM-component has received tremendous focus and various open source solutionssuch as OpenStack and has been used to realize the virtualized infrastructure management functionality of MANO.
As seen from the above figure, for MANO to function well, it must be integrated with aset of interfaces, preferably open, in the existing systems. According toETSI, the MANO function is responsible for deploying and connecting hosted elements orvirtual network functions.
The telecom industry agrees thatto realize various benefits such as enabling greater flexibility, agility and operational functionality; one has to address MANO correctly.
As mentioned by many experts, NFV MANO is one part that is left open, rather widely, to vendor interpretation and extensions. For example, Open Networking Foundation board member Axel Clauberg , of Deutsche Telekom, has noted there is a “zoo of orchestrators” out there referring to different vendors’ interpretation of what is still a weakly defined component of the NFV reference architecture: the NFV Management and Orchestration (MANO) stack.
Also, Clauberg adds, every vendor seems to market their solution as “open,” but when looked under theproper microscope, it’s difficult to understand what “open” truly means. One should be skeptical of “open” APIs that are still proprietary.
1.1 The OpenStack DilemmaA popular question that popped up some time back, and probably still exists, is: Should OpenStack be enhanced to cover all aspects of MANO or not? Though some experts suggest that OpenStack is sufficient to fulfill MANO requirements, others argue that OpenStack is an element of the cloud VIM and should be a tool in NFV MANO.
Overall, amajority of the industry experts are against the idea of having only OpenStack for MANO, mainly citing the reason of thepresence of legacy equipment or solutions drawn out of legacy equipment. OpenStack lacks specific mechanisms to support many of the services and service components now deployed using legacy network equipment. Also, as many legacy elements have their management and orchestration tools, implementing MANO features, then OpenStack does not need to evolve beyond its mission to manage the infrastructure of the cloud and only the cloud.
On the other hand, since nearly all NFV deployments originate in a cloud, OpenStack, which is extremely popular in managing such virtualized-infrastructure, could be enhanced to support all the NFV requirements. That would make OpenStack even more powerful, and perhaps foster the growth of NFV deployments.
Also, OpenStack could present a faster path to open MANO, particularly if current efforts to start an NFV initiative within OpenStack lead it to a broader MANO-like capability set. In summary, though the trend is to develop additional orchestrators and managers to work with OpenStack, things may change if such orchestrators/managers do not remain truly ‘open’.
1.2 OASIS TOSCA and its support by MANO solutions
An OASIS standard, TOSCA (Topology and Orchestration Specification for Cloud Applications) aims to standardize how to describe software application and everything that is needed to run that application in cloud environments. TOSCA is designed to facilitate the ‘portability’ and ‘lifecycle management’ of cloud services. TOSCA supports many cloud orchestration tools such as OpenStack Heat , Cloudify , SeaClouds , Alien4Cloud , etc.
1.3 Implementation Challenge The Current State. A well-researched study by Heavy Reading quotes that, in practice, amajority of implementers do not stick to ETSI NFV ISG’s description of three functional layers of orchest