 Hey folks, good morning. Thank you for coming to our session this morning. I know it's pretty early. Telco, NFV, management in a distributed and heterogeneous cloud is our talk today. My name is Sudhir Ketamaka. I lead an engineering team working particularly on the cloud management solutions at Ericsson. And I'm Harshat Tanna, I'm chief architect on the cloud manager product. We work in the same team basically. So, I know the focus of our talk today is distributed and heterogeneous cloud for the network functions specifically. But before jumping into the crux of the conversation, I just wanted to set a context like talk about NFV a little bit, what's mono from an Etsy perspective? We won't dwell too much on that and then Harshat is gonna take over and talk about the challenges in the distributed cloud and also the heterogeneous cloud. And then a little bit about how Ericsson is working with the various vendors in the community and also the OpenStack to solve these problems in the industry. That's the agenda today. And then we'll have a few minutes for the Q&A. Okay, NFV, obviously the motivation behind this is in the past decade, all the efficiencies, all the gains that the IT and the business and enterprise applications have achieved. Either by balancing out or by conserving the resources in one area versus the other, et cetera. And the telco also want to go into the same direction. So some of the operators along with the vendors came up with this idea of NFV. There is a slight, I mean, you must have heard about this a lot like there are some similarities but at the same time we have some stringent requirements on the high availability, scalability and the five nines, whatever for the telco applications and the network quality of service, criticality of the management platform. I mean, this is something interesting because my 15 years in the industry has been mostly on the management side of things. And even though the applications there are more like IT and enterprise are more like IT, still the requirements are more like the network application. So management platforms are also very, very network driven, I would say, or critical from an HA and stability perspective. So close loop control for automation is extremely important in that area. And higher level of automation, this goes for everybody, even in the IT field, it's a common thing. Now, so in Etsy, it's really, it's not standards yet. I think people are working towards that. And this is what the NFV management looks like. Hopefully, you have seen this picture before we got directly from the Etsy. So NFV functions as like industry specifications group in the Etsy. So working with some of the major operators and service providers and vendors, the community is gathering requirements at this stage and trying to come up with some standard mechanisms on how to solve this problem. So I think the phase one is almost ready. This is what phase one looks like. They have come up with like various components in the NFV architecture. And as you can see on the left-hand side, the OSS, BSS. And this is gonna be the focus of our conversation, the NFV orchestrator and VNF manager and virtualized infrastructure manager. They kind of form the whole mono in the picture. So I mean, VIM, obviously that's the closest to a lot of people here from OpenStack who are attending the summit. But of course, I know OpenStack has been also looking at a few other aspects of this architecture. Some of the vendors are looking into that. And NFVI, that's where the infrastructure kind of sits on the hypervisor layer. So that's the overview of the NFV management itself. I'll just go like a few minutes into the various peace parts of the mono itself. And so NFV orchestrator. So it has like four main components, like driven from the VNF and network service catalog. And network services, again, you cannot control them to be just, or you cannot confine them to be just like virtualized. The service could have other needs to connect to other PNFs, the physical network functions, et cetera. So a network service is a little bit more than what a VNF can. So both the catalogs are required by the mono. And then we also have the inventory part where NFV instances and NFVI resources are also stored in the network, in the NFV orchestrator. And also there is mandate, it's not a mandate, but there's a requirement where a single instance has to orchestrate more than one pod or a WIM depending on your needs. So it's like one to many relationship there. And manage the lifecycle of network services spanning multiple VNFs. So different applications needs to be managed. VNF manager, this is the other main component in the mono. It's the management and orchestration of VNF lifecycle. So uses the VNF catalog in the orchestrator. Typically, VNF managers that we have been looking at, they are more specific to the applications because application vendors know exactly what the needs of the application are, what the lifecycle should be, how to provision, monitor, decommission, et cetera. So that has been the traditional trend, but I think there is some hard work going on to come up with a VNF manager that is more generic. But it's a little hard to generalize, but I think we have solved problems like that before. So I'm sure we will see that pretty soon. And the next part is the virtualization manager. So this is the, we call it pod cluster data center, point of presence. And this is the heart of it all here to manage the compute network and storage resources on the VNF VI layer. So all these things together, there is still some work going on. Nothing's 100% standardized yet, but I think we are at a point where we can, in fact, we have already started some of the, to realize this in the actual service provider and operators world. So having said that, I will turn it over to Harshad. Right. Thank you, Surya. So we have gone over the framework of Etsy NFV Mano. And we kind of, Surya touched upon the fact that a single NFVO that is at the top, manages many VNFs, many VNF managers, and also many virtualization infrastructure managers that are managing the NFVI, which is the basic compute network and storage platforms in data centers or pods or whatever, the way you have instantiated this NFVI resources. So there is already the standard rise. There is already a concept that a single orchestrator needs to manage many VNFs. And the critical part to realize in case of telco operators is that many telco operators have continental or even transcontinental footprint. And as a result, they invariably have many data centers, typically 510 and in some cases, we have talked about with some tier one providers, their desire is to ultimately go to 100, 200 data centers where they will like to instantiate the virtualization platforms and manage it from a centralized location so that they have centralized control orchestration of all their virtual network functions which are interconnected with each other and they provide services for all the good things that we know about the mobile phone, wireless and telephony, whatever it is. So that is one of the reason why we are talking about distributed clouds. I'm sure this is true in many of the IT applications also, but it is very, very critical as far as the telco industry is concerned. So the idea is that you have distributed cloud infrastructure and you should be able to create a single logical cloud out of all these distribution that you have in the network. So that is the definition of what we are going to talk about in the distributed cloud. The second aspect of telco infrastructure is the heterogeneity that we are seeing. And this is, as a result of many factors, most of the telco operators that we are talking with, tier ones especially, they are behind OpenStack and you see their presence here in many forms. Many of them are presenting, many of them are present here in the audience, I'm sure. And they are standardized on OpenStack and KVM going forward, but there are still workloads that prefer other virtualization infrastructure. And also there are already virtualized workloads that are running in some other infrastructure and they have to be folded into under the same management umbrella. So that brings in the aspect of heterogeneity. So you have many distributed data centers and many types of distributed data centers that you have to manage. So you could have OpenStack, hopefully majority of them are OpenStack, but you have to have managed VMware as well as other VMs that may exist in the infrastructure. So that's it. So let's then go into what are the critical aspects and how we deal with that from Ericsson as a solution. So the first aspect of the distribution is the orchestration and resource management for this distributed cloud. What it brings is when we think about it, when you are talking about a single data center that is made up of maybe 100, 200 blades or maybe a thousand blades, it is one thing to talk about that scale at that level, at a local level. But now you're talking about maybe hundreds of data centers, some of them may have just five blades because they are deployed closest to the customer's demand, where some excess level network functions or applications are deployed. And then there are some large data centers with couple of thousand blades, but you have to manage 200 or 500 such data centers. So the scale of the orchestration is very different and you have to basically divide and conquer. So the approach we took is that at the course level, the NFEO does the orchestration for the functions and the local orchestration at the host level is left to the WIMPs. A typically open stack already does that with no one neutron schedulers, whereas in vCenter again you can use vCenter to do the local level orchestration of the workloads. So the other aspect that it brings in is the way to describe the workloads and that is another critical part. And standardization like OVF formats or HOT and TOSCA are very critical so that you can describe these workloads in a single format going across all the platforms. You don't want to be tied to one type of orchestration because that may not work with all the platforms. So those are the two critical things and once you have this level of orchestration you also need to manage the data as a result of that. So you have resource information coming from all the data centers. You have to manage that in the centralized manner. So what you see on the left side is the orchestration catalog, CMDB and activation. These are the four components that make up the kind of platform that we need for this kind of distributed cloud and we have put together that in our cloud manager product. The second aspect of such centralized management is a common GUI and common security environment. And I think a lot of people have talked in the federation, at least for the open stack where we are talking about Keystone Federation which is very, very important for us because we did exactly same thing whenever we have open stack Keystone Federates with ForgeRock OpenAM platform that is part of our solution and so does the other platforms that can work with OpenAM. So the security is implemented using a centralized platform with a back end from the WIM level to connect to that. And there is a common northbound API and GUI layer that provides an abstraction of all the telco services, both the network services and VNF level services on that API. And the abstraction is common across all platforms so that you don't have to, user and user doesn't have to know the differences of open stack versus how vCenter manages the resources. The third aspect is the fault and performance management. This is probably bread and butter of the telco operations because without having a solid fault and performance management system or having the needed visibility for fault and performance the no operation team in telco will accept any management system. So we have to have capability to collect large amount of fault and performance data from this distributed and heterogeneous platforms and also store them and present them and give visibility to other systems that may work in conjunction with this platform. So in the Sude showed in the very beginning slides in the architecture you see that NFVO connects to OSSBSS system. So idea is that fault and performance data at the infrastructure level is collected by the NFVO and then it is exposed to the other system so that it works in the rest of the ecosystem. So we in our platform have implemented fault collection mechanism and also performance data collection from the silometer for open stack collecting the performance data from directly from vCenter in case of VMware and presenting that in a consistent fashion to the end users of the system. So that is about the distributed nature of the cloud and how we handle the large infrastructure. Then now the coming to the heterogeneity. So we did talk about adopting to open stack vCenter or Citrix environment or even the public clouds like Microsoft Azure and AWS. So how do we do that? The approach we took is that we keep the services within the platform kind of at an abstract level all but at the lowest level of the components in the system. So what you see is that there are two components in the system, the activation component and fault FMPM data collection components. So this is where we provided a framework to provide the plugins for different type of system. So you could basically you could create a complete new adapter for a new virtualization management and plug it into that layer so that for the users that becomes available for the services just like any other platform they were already working with. And this makes it very, very easy to keep it extensible and maintainable over time. The heterogeneity in fact is very, very important because not just between different type of VAMS, even within the same type of VAMS, what happens is that today some data center starts with let's say Juno release. And then there are some new data centers that get installed with Kilo release and there are some minute differences. You should be able to even take care of those differences with this kind of adaptation. So that's the platform's capability that is quite critical. So now switching the gears a little bit. So we did talk about how we do this with NFVO implementation but looking at the broader picture this is the complete portfolio of Ericsson. So as we talked about there is a cloud manager piece that implements the generic Vienna management and NFVO component but there are two other platforms or systems that are important in completing the whole picture. Ericsson network manager, this is the next generation OSS systems for OSS and EMS system for Ericsson virtual network functions. It works with Ericsson cloud manager as well as third party platforms and controls the Ericsson virtual network functions lifecycle irrespective of what infrastructure they are running on. And the second important, other important component is the Ericsson cloud execution environment. This is an open stack based platform. It is hardened for the telco environment and we work very closely with our distribution partner Mirantes and we also do announcements and contribute to the open stack for that component. So going over the details of the various functions we have kind of talked about Ericsson cloud manager. It provides the NFVO and the Vienna manager for distributed and heterogeneous infrastructure. We talked about that it has secure GUI and REST API layer as well as telco reliability for closed loop control for some of the automation that is crucial in a telco environment. The network manager we talked about the critical functions there are the application management, application lifecycle management, the F caps management for the telco applications because some of the applications in telco are very, very complex and they need a solid foundation, a solid platform to operate them in the telco environment. And this platform actually is an evolution of already existing OSS system that control many of these functions in the physical environment. And the last component we talked about is the cloud execution environment. Like I said, it is high performance, high availability and a secure platform. And also expose is the same good APIs and interfaces that OpenStack provides for all the other applications to work on. So I think that's the picture of how we saw this whole puzzle of telco NFV environment for distributed and heterogeneous infrastructure. Yep. Yeah, we still have a few more minutes. Should we go to the Q and A? Yeah, I think so. Before we go to the Q and A, I just wanted to get a poll on how many of you are from the telco field, like. Okay. Great. And do you believe in this thing that, you know, it is possible to have the network clouds from, you know, heterogeneous? Like there's no, it's not possible to kind of confine it to a single vendor or single type. And so a good, because we got some challenges on, you know, talking about this concept. I mean, we did start off supporting more than one type of VIM. And of course, OpenStack is our kind of de facto cloud. I mean, when we go into selling this idea, we start off with, you know, we try to put everything in a box and we do try to say OpenStack is the preferred thing, but you go to the brown fields sometimes and there's no guarantee that people are willing to migrate from their existing clouds to OpenStack right away. But, you know, yeah, of course, if you have a green field situation, you know, you can start off from scratch and everything is awesome. But so I think this is a real problem that. Yeah, but I would just add that even in green field, ultimately you will end up into the same situation. It could be. Yes. Yeah. Please. We don't have a mic, unfortunately. So we'll repeat the question. Yeah. It's a very complicated task because you are moving the project. So instead, if you go and actually manage the application processes and move them, then you have a much easier role. Do you see performance gates and, you know, for telco brain moving virtual machines is the right thing? So. You want to repeat? No, no, go ahead. So I think the correct me if I didn't get the question right, but I think the question is for the telco environment and moving the infrastructure from the physical to virtual is one thing, but your question is, well. Migration. Yeah. So I think the question is rather than doing the migration of virtual machines, assuming that the services are stateless, because otherwise sometimes when you do that, the application logic, because it is stateful, breaks. So applications break. Rather than that, make the migration stateful. Is that the right approach or not? Is that the question? So I think that is very important because, and this is where the sum of, I think one of the comments that Sudhir made is that the current position in the telco industry is that a lot of these VNFs, the virtual network functions or simply called network functions, they are starting with VNF specific network VNM managers. And this is the key reason, the point that you are highlighting is the key reason, because some of this logic has to be known by the application managers, and that's why the VNFs are combined with the application specific logic that comes in the VNM manager, and you have to work with in that kind of scenario. And that manager is able to keep the state and manage the state in the transition. So that is important. Yes, we agree. Yes, please. The question is, how do you achieve service chaining across heterogeneous cloud, and whether Ericsson Network Manager is capable of doing that? So Ericsson Network Manager has a component called IPTE. I think it's a network service manager that is able to manage the network services across the physical and virtual environment. So if you have physical switches and routers, as well as some SDN controllers for some parts of the network, it is able to stage this virtualized network services or virtual links across that kind of infrastructure. In addition to that, one of the key aspect of the cloud manager is that it has an extensible orchestration platform, so that if there are gaps, or if you don't have a network manager, because all three products, we are not saying that the environment where any of this component is going in has to have the full portfolio. All this is based on standards. So as long as the interfaces are met, you could have cloud manager and the execution environment, but the network manager may not be there. And if there is no equivalent substitute for network manager, the cloud manager has capability to write extension orchestration flow that can work with the physical network functions as well as the SDN controllers to stage together such a service-changing scenario. Any other questions? Any other questions? OK, great. So if you have any questions about Ericsson portfolio or what we are doing in the, we are also like big on OP NFV. Ericsson is contributing requirements 24 by 7. So if you have any questions about our portfolio or NFV in general, Ericsson Booth is S7. It's in that in the middle. Please do visit us. There are a few demos also. Please do visit and we have some very good demos there. Thank you very much. Thank you.