So in this section, we're going to talk about what management and orchestration means in an NFV context, and really what it means to a Telco. Here, we're going to look at the three major layers of management and orchestration, which by the way, usually get shortened to MANO, which is probably how I will refer to it from here on. And we'll map those three major layers to the NFV reference architecture model that was proposed by ETSI in one of the early NFV white papers back in 2014. So MANO describes a very specific architecture, consisting of three main layers. Those layers consist of an entity called an NFV Orchestrator or NFVO, which is primarily responsible for resource orchestration, a VNF Manager, which has more of an application or VNF centric view, and a virtualized infrastructure manager, which is more commonly known as a VIM. So taking these layers from the bottom, let's start with the VIM. Probably the most common example of a VIM, at least from the open source world would be open stack. And by open stack, I really mean the core components of open stacks, such as Nova, Newton, and Glance. The VIM is responsible for controlling and managing the NFV infrastructure by either compute, storage, and networking resources that the VNFs are going to be deployed on top of. It's the entity responsible for the allocation, the upgrade, and release of resources. And it plays an important role in the capture of telemetry from the platform. Next up the stack is the VNF manager or VNFM. This is responsible for the lifecycle management of VNFs, and it will include responsibility for actions, such as configuration, start, stop, scale up, scale down, those types of functions. Lastly, the NFV Orchestrator or NFVO is responsible for NFV infrastructure or orchestration across multiple domains. That could be across multiple sites, for example. Or it could be across multiple different VIMs. And it's responsible for higher level actions such as rolling back an entire deployment. So these three layers together are what make up what is typically known as NFV MANO. But to complete the picture, we need to briefly describe some other layers that come together to create a complete solution. Now, these were mostly held to be out of scope for the original definition of MANO, as proposed by ETSI, but they remain important components of a complete solution. So at the top, we have the Service Orchestrator. Now the Service Orchestrator works at a higher level, and it's focused on the end to end operator view of a service. There is a connection to the MANO layers, low as one of the requirements of a Service Orchestrator will be to drive consistency between the resource allocation and the VNF configuration. Lastly is the SDN controller layer. Originally, this was also considered to be out of scope by the NFV standards organizations. But that's somewhat changed over time. The SDN or software defined networking controller is, of course, responsible for network management. It's also responsible for the ability to do fine grain control of network resources, to enable things like service function chaining. It's responsible for the network underlay and overlay management and for the debug of those network components. And the picture here shows three possible deployment points for an SDN controller in an NFV architecture. For example, as in example one, it could be deployed as part of the VIM where neutron in open stack would be a good example of this deployment model. So moving on, let's consider the purpose of MANO and really think about what problem statements it's trying to help solve. So if we try to identify the steps that an application or VNF goes through during its life cycle, we can maybe simplify things as in this diagram. A VNF vendor will need to design and develop and deliver an application to their customer. And then the next step really is the onboarding of that VNF into the customer or service providers environments. The creation of a entry in the service providers service catalog and various testing and validation steps to ensure that the VNF will run the infrastructure and perform to its required key performance indicators. So this really is the point at which MANO starts to come into play as a service provider on board a VNF into their environments. After the onboarding process, the service provider will need to instantiate or do a Nova boot of that VNF for the first time. And then we move into an operation phase, where configuration policy will be applied. The next major step in the life cycle is once the VNF is being configured and is moved from its day one state into its day two running states. We need to continually assure that he is continuing to meet its key performance indicators. And as these VNFs typically will live in the network for a long time, there will be a maintenance phase where upgrades and patching will need to be applied. And then finally, there will be a phase where the VNF is being retired and the resources need to be returned to the pool and cleaned up properly. So although this is a high level and simplified view, I hope it gives a picture of the parts of the lifecycle of a VNF that MANO concerns itself with.
