 All right. So first of all, welcome. My name is Harshatana. I am Chief Architect on Cloud Manager of Product from Ericsson. My name is Sudhir Ketamaka. I lead and manage a product development team that's working on the Cloud Manager solution. But I also have a unique opportunity to play a solution architect role, helping Harshatana and some of our solution architects working with the customers. So first of all, thank you for coming. I know you have a wide choice of talks at this prime time, pretty close to the lunchtime as well, and great turnout. We are glad to see you all here. Clearly, the organizers have underestimated the telco interest in this summit. They gave us all room for all the telco talks. So next time, probably, they will do a better job. OK, so today's talk is about NFV orchestration going beyond virtualization. So just like everything else in software and life in general, there are multiple ways to do these things. And this is our view. Nothing here is based on speculation. It's from our experience with some of the real deployment in the past year or two years, and also some of the POCs that we are doing with tier one customers around the world. So Harshatana and I gave a talk in Vancouver also about NFV orchestration. We emphasized how important it is to look at heterogeneous and distributed clouds, especially when you are in this telco NFV paradigm. The reason is you cannot assume a greenfield deployment. So you all by now very well know what NFV is. And why we are doing this. Just to add to that, in fact, there were a number of talks. We are happy to see that there were a number of talks this summit talking about the same topics. And so we kind of started a bit early, about two or two and half, three years back. But we see that our assumptions are getting validated. And glad to see that really happening in the industry. Some of these things that we are going to talk here are certainly debatable. So we'll leave some time for questions at the end. But please hold off until the end. And there's not too many slides. So you can even remember the slide number and just point to the slide back. And we can go back and talk about it. All right, let's get started. Since our agenda, I'm not going to go too much into the detail on what NFV is, what monoframework is. I think by now, I'm expecting a lot of you have been attending the talks about NFV or know something about telco NFV. So we'll go through the orchestrator, what we meant by going beyond virtualization, and then what Ericsson is doing about it. And a brief talk about our Ericsson Cloud portfolio as well. All right, this is the NFV overview from as defined by the ISG in Etsy. Not a standard yet proposal. And a lot of things, I think it evolved quite a bit. And several of these things are getting there. Key elements. And we are going to focus today mostly on the orchestration and the management part, which is the mono and the virtual infrastructure manager or managers, which is the open stack, is also part of it. Open stack kind of falls between the NFVI and the VIM layer, as most of you very well know. So the framework here mono meant NFVO, the VNF managers, the domain managers in the past, and plus the VIMs constitute, they kind of enable the orchestration of your network services and the management of your network services. Key elements, like I mentioned, the virtual applications, network functions, and the VIM, NFVI. One thing, we started the cloud manager solution two and a half, three years ago. And at the time, there was no division of managers versus orchestrators. But clearly, every VNF, we see in the telcospace, have their own domain managers. And it's inevitable that there would be something called a VNF manager that would be doing that in the virtualization as well. However, in the absence of such a thing, we did come up with the concept of generic VNFM as part of our architecture and the planning. We'll talk a little bit about that again. What's beyond virtualization? So yes, I think if you look at the picture in the middle, these are most familiar network functions, virtual IMS, EPC, CDN. If you just take them as applications and you want to deploy them on the virtual infrastructure, absolutely, I think OpenStack has evolved quite a bit. Some of the other vendors are also coming up with virtualization solutions. But I think the closest is definitely the OpenStack. And there's a lot of support from, especially from the telco industry to take that as more of a de facto VIM and NFEI. So we are glad to see that. And if it is just about virtualization, I think we do have a lot of tools in OpenStack. Ecosystem and a little bit about that. Heat was introduced to orchestrate and deploy resources. There were IT tools like Puppet, et cetera. They were doing a great job with the deployment. But the story doesn't just stop at virtualization. It's the whole lifecycle management of your network services and your network functions. What do we need to do when you are in that, when your role is to manage and orchestrate? Here are the few things that we saw as the challenges that we need to face or solve when we have to support the orchestration and management of network functions. You have to be able to customize and extend. This is both your interfaces and your functionality. You have to provide secure and open access. It has to be operationally ready. So FCAP support, service assurance, operations integration. You have your existing systems, legacy, or even advanced systems that a lot of you know, I think this is the biggest challenge, especially in the telco industry, where operations is always something that people try to solve at the end. But it is like the most important thing when you are trying to actually launch a service or a launch a function. And then physical infrastructure connectivity. This is not going away in the next year, two years, three years. You all know that. It's a nice dream to have everything virtualized, but that's not the case. And for a long time, we will still have to support the physical network and infrastructure connectivity from your virtualized world. OK. Let's dig a little deep into that. So what is needed? I can mention open and secure APIs in various layers. You saw the monoframed work. There is like OSS-BSS systems talking to the orchestrator and then an orchestrator then communicating with the domain managers or VNF managers. And then there is interfaces to the WIMS for resource management and to collect the information. So all these interfaces are supported by the APIs. And you need to have open and secure APIs. Adaptation and extension framework. So that's the biggest challenge. VNF is not a VNF. Network service is not every service is same or not every function is same. So even for a specific, let's take the case of an EPC, you try to build, as a vendor, you try to build with your own EPC solution in your company in mind. And then when you are just playing a role of an orchestrator, you go and try to integrate these things, you will find surprise, surprise. It's not exactly what you thought it would be. I mean, people follow standards to some extent. But then there is always extensions and adaptation required in every layer that we are talking about here. And the biggest challenge, like I mentioned, when it comes to the operations, performance, and fault management, and virtual and physical network connectivity, I think there has been a tremendous amount of work that has been done in the past year, two years, whether it is SDN controllers by various vendors and even the standards have been evolving. And there are still a lot of challenges. I think we attended some talks and some of very good points were brought up, hopefully the community and also the standards bodies will address these things. But that is still like a reality that you need to have connectivity. OK, I'll just go one by one and talk about what we mean by the open APIs. Kind of clubbed in the VNF catalog in there. So the definitions could be by the standards such as open virtualization format, TASCA, and also the heat templates are getting a lot of popularity these days. So you need to have these standards-based catalogs in your system. OSS, BSS, and not-born systems. So I think most popular ones, HTTP REST or so-based APIs. Again, not every operator's OSS, BSS system is the same. So you need to have, again, some level of openness there and, of course, security as well. Third party VNF managers. So again, I think we all know that some of you are from the vendor companies just like Ericsson, Juniper, Brocade. You have a certain view of domain managers in mind when you're building your orchestration solutions. But again, when you try to integrate with other vendor solutions, and you will have to because that's what is going on. I mean, if you're from any of the tier one operators, you know this very well that you're not getting all the VNFs and services from the same vendor as you're getting the systems integration work or orchestration. So there need to be a lot of openness in the APIs there. Element management, EMS systems, same story there. VIM APIs. I think OpenStack has done a very good job with respect to the core like now storage, compute, networking. Networking is still evolving. I think there's a lot of talks about what is needed from the telco perspective. But there are only concern in the API layer would be some of the operations side of things, like how we can gather information about the faults in the system or performance of the system, et cetera. That I think still needs to be evolved. And resource information is still something that is lacking there. Right. And last but not the least, the network infrastructure itself, like talking to Neutron or OpenDeli8, et cetera. OK. That's the API part. And next is the adaptation framework. What do you mean by that? If you see those yellow rectangles there, so the APIs are there, but then it provides you some sort of a structure or interface. But then functionality-wise, the behaviors are different again. So in each part here, like the orchestration framework itself, you have to enable or you have to provide the trigger points or plug points so that every new solution can introduce custom logic into your flows. And the second one is extremely important, interface adaptation for network connectivity, such as SDN controllers, physical network elements, network management systems. So not everything is so pressed HTTP. So we are talking about a lot of systems talking, NetCon, CLI, SSH into the systems to do the configuration post instantiation of these virtual resources so that there can be connectivity established between your VMs and the physical elements. VNF manager interface adaptation, again, from our own experience, we had to introduce, we went with certain assumption, but when we get to an actual solution for a particular operator, we had to go and introduce some trigger points where there would be some custom logic involved even in that area and adaptation of various EMS element management systems. OK. And I'll let Hashad take over and talk about the next two challenges. Yeah, so thank you, Sudeer. So like Sudeer said, there are standards that are being defined, but they are still not standards. I think more or less all the vendors and telco providers are together in this journey that we want to have standards at these APL layers. But in the absence of actual standards, these adaptations on some of those APL layers that we talked about is very, very critical. And I think that is going to be the situation for quite some time. And there are adaptations that will have to adjust to that. OK, so the next topic that we are going to talk about is operational readiness, or as Sudeer said, service assurance, fault, and performance management. Now talking about the virtualization is one part. But when we are talking about the virtual network functions and network services, it involves a whole lot of infrastructure that is still not virtualized. And you also have elements that are new elements compared to what you had in the earlier physical network function implementation. You have the whole WIM layer. You have the NFVI layer. And you have to be able to take the fault and performance data from all these layers, correlate them, and provide a holistic view to your operations team. Otherwise, the system becomes very hard to use. And when you talk about we are just starting, but when we are going into production, and these things are supposed to scale and have the agility to scale up, scale down, and put together the VNFs and services in a very, very short time, if you don't have the tend to end visibility into the operations data, it will be a real problem to actually be accepted in the telco operation environment itself. So that is the key aspect. The other thing that you have to be able to do with the NFU and the VNF managers is to provide highly available and disaster resilient platforms. Because most of these use cases now require that even though these are the management systems, they will be in some sort of a closed loop operations control. And having the downtime on these systems itself is going to impact the services in some form. So that is another new aspect that you have to be aware of. The other aspect of the VNFs and network services, like we talked about earlier to begin with in the first slide, that this is not virtual network functions are not sitting on a virtualization platform in isolation. These are not simple compute services that where you can deploy, let's say, 50 VMs, they do compute job, produce the result, produce the data, and they quit. It's nothing like that. These are the virtual machines that are getting connected, providing the data services in various forms, voice, video, and whatnot, to users who are connected in some physical form over the wide area network. So after creating the virtual network functions, stitching them together into the physical and networking infrastructure is absolutely critical. And if you don't do that end-to-end orchestration, you are talking about multiple systems. Now users have to go from console to console. And again, it is another operational nightmare if you do that. So having the adaptability to connect to a wide variety of physical and network infrastructure that is already there, and that will be there for quite some time to come, is a key requirement. And so are we just talking about some theory here? Or so far, we have been talking at a very, very high level. What are the requirements? And this is based on our experience, like Sudhir said, in number of tier one operator proof of concepts for this whole infrastructure, as well as some real-life integration with other vendors and systems in this environment. And we started the journey about three years back. The result is that the NFVO and VNM manager, Henry Quinn, VNM manager, was built as a cloud manager product in Ericsson. It basically covers the aspects that we talked about. We have an orchestration platform that is capable of orchestrating the VN apps and virtualized services in a geographically distributed infrastructure, and also stitch together the whole end to end flows and provide the operational capability using the FCAPS data that is being captured from all these wide variety of platforms. So that is a little bit about the product that we are talking about. These are some of the screenshots from the proof of concepts, et cetera, that we have done, showing you what the services look like, and you have some configuration management and some physical network function connectivity that was shown there. I think one of the slide had that. I think you have DNS server and it has a controller integration. And going a step further, the cloud manager product is just one part of the Ericsson's portfolio. Ericsson's portfolio covers the entire ecosystem of network function virtualization, and it consists of basically the Ericsson execution environment, which is based on OpenStack. We are providing the VM and NFVI layer. We have a brand new hardware platform, HDS-8000, which is a high-skill architecture. It's a disaggregated data center, if you are interested in it, you know, Ericsson Booth has a prototype as well, and it's pretty cool. And we have Ericsson Cloud Manager as NFU, and we have been a manager. And our network manager, Ericsson Network Manager, is specifically a manager for some of our virtual network functions in the environment. So that is the overall portfolio we have. In summary, we talked about four things. We talked about the need to cover virtual as well as physical network connectivity, fault and performance management, redundancy and disaster recovery. Adaptability is paramount, and standard APIs is what we need from such a platform. So I think with that, we are ready to take any questions you have. Can you come to the mic, please? I'm from China Mobile, and I do have a question. I see the slides in the middle. So your orchestrator can manage both non-working and, I mean, manual part, right? In the previous slide, you showed the network orchestrator, I mean, and also the separated Cloud Manager. So are you talking about the network orchestrator and the wing orchestrator, manual orchestrator is separated? What do we mean here? Can we both do that? No, they are not separated. Can I go slide back? Yes, you should. Next one? Next one? I mean, this one is integrated, but the second last slide, I think, this one? This one is integrated. I understand. Oh, you're talking about the next one. The portfolio. The portfolio. OK. So the network manager is, oh, the name is a little confusing. It's actually, it's a VNF manager for direction network functions. And it's a portfolio product. It's an existing product that already does the legacy. Already does the network function management for the physical functions. So you see that traditional native deployments? Then you have a separate either VNF manager. Right. So for Ericsson VNFs, we do have a domain manager. We can call it a specific VNF manager, but it does address the needs of various network functions in Ericsson. In absence of that, when a cloud manager is integrating, in absence of Ericsson network functions, then we do act as a generic VNF manager. That means absence. If not absence, so who is going to make this decision? So then the interface would be the NFV or VNFM interface. There is a VNFM interface between network manager and cloud manager. That's this interface. This would be the ENM, Ericsson network manager. This would be the Ericsson cloud manager in that. OK, so still, this one is top. Right. OK. Thank you. Sure. OK, so let me try different advocates. In a sense, integration with new technology, especially automation, with existing infrastructure has always been a challenge in any IT operators. So what do you think is the most peculiar thing in telco operators, which makes NFV very difficult to adopt? So let me repeat the question and tell me if I got it right or not. So the question is this kind of integration of new technologies in any environment has its challenges. But why is even more of a challenge in telco environment? Is that the question? Yes. OK, so again, my view, I would say the amount of infrastructure that exists in telco is tremendous. It is the infrastructure that you see today has been built up for the past 40, 50 years. And that infrastructure is not going away anywhere. Telco has very strict methods and operations that are required to provide the reliability. And some of this is in many domains of the world, it is mandated that they have to provide that kind of reliability. So integration of new technologies in that kind of operational environment is even more challenging because nobody is going to take any chance by just introducing a whole new technology without going through a lot of testing, a lot of verification. And that's the main challenge. Did I answer? Yes, it makes sense to me. So in the short words, the conservativeness of telco operators. I'm sorry? Is they a conservative? You can say that way. But it's a conservative for a reason. It's not just because they don't want to change. You see a lot of telco operators here, and you know. I mean, they have a very good reason why they are conservative about it, right? And we all know that, just the sheer size of the system. And you will see same thing in utility. If you want to go to utility industry, if you introduce new technology, these are the industries that are providing infrastructure. You can't just throw new things in there. Yeah, I know in that sense, every industry has its own difficulty and conservativeness. So I want to understand what particular in telco operators. Yes, it's a scale. You can say scale and the requirement for reliability that they desire. Okay, thank you. Yeah, thank you. One question, with tackle and heat coming, do you believe vendor should continue to spend money in orchestration functions like that, or do you believe it's going to take over anyway? I expected this question. And you can also say tackle. But here's the thing, right? When we started this journey, none of these guys existed, right? But we are looking at every one of them, and actually Ericsson Cloud Manager does support hot as one of the formats that you can deploy the system. So we do support stack operations as well. But like I mentioned in the beginning, it does solve, he does solve the orchestration at that particular whim. And yeah, there are some talks this time about multi-site, et cetera. We will definitely look at that. These things keep coming up, but the story, the whole story just does not stop at supporting orchestration and deployment and also supporting multi-site. The reality is you will be in a multi-vendor situation, right? And you will have to support customizable interfaces. So it's a services opportunity rather than a product opportunity? Combination, because we are ahead of the game, if I may. But yeah, it is still a services opportunity. Yeah, and if I may add, it's virtualization and its orchestration, it was going to happen. It is a no-brainer. It's not telco requirement. Orchestration of these complex workloads is required everywhere. So heat was going to happen. Multi-site is going to happen. And we don't want to say that, OK, we don't take advantage of that. Industry should take advantage of that and build on top of that. But some of these aspects that we are talking about, they have nothing to do with virtualization. And that's why the topic we chose, going beyond virtualization, what else do we need in the orchestration platforms? So that is why some of these aspects, F caps for the applications, you have to build that. The orchestration of physical network services, you have to build that, right? So it's going to all coexist. Nothing is going away. Can you open the slides? We were seeing, I think, the previous, I think, more. Oh, yeah, that one. I see the EMS, the VNFMS, is connecting to the third-party devices. I know that you guys are from the Erikson. You can connect to the Erikson devices. But you don't know how the other devices are. The CLIs, I think you guys can see the manuals from the other Windows devices. How are you going to develop the connectors, adapters? They are not out of the box. That's why we talked about the adaptation framework. So your framework is not rigid, and they're not fixed hard-coded APIs. You have to support some level of customization. So trigger points. If I do this, then you provide hooks into it so that someone can introduce custom logic into it or custom parameters into the flows. So that's where we are open, like providing a customer adaptation framework. So the customers, up on the request, what the customer want to use, the specific functions, then the part is developed. So the part cannot cover everything out of the box if anybody claims that they can cover everything. Just run. I understand. Thank you. Thanks for the question. So just to extend on that a little bit, the plug-in approach which most vendors use has its challenges from release management and future feature support. What are you guys doing to enable that to be a little bit smoother from a transition perspective? I think that is a very important point. Basically, you want to drive that plug-in with some loose coupling. If you say that this is Java SDK, you are in that lockdown situation. Plug-ins have to be upgraded as soon as your framework changes are done. So keeping the loose coupling, and that's why I think Sudhir kept mentioning some of the triggers, the approaches we follow are like REST APIs, REST-based notifications, the callbacks, et cetera. Or message bus or things like that. Which decouples things completely so that, yeah. So I challenge vendors, and I'm being one of them, but is that going to make life easier or is the complexity of having so many plug-ins for so many different devices if I want to be in a multi-vendor environment going to be actually be a supportable solution from a carrier's perspective? The last point I'd like to make is though is there's two kind of models. Yes, everybody can use a plug-in which gets to your common bus, basically, or any other vendor's common bus. The other model is to have a standard for what the interface is, not the actual protocol used to transfer messages, but what an interface should look like and try to get vendors to standardize for their VNFs for that. Is that a model that you think is viable? Absolutely, that's the direction that we are talking about, but is it going to happen in one year, two years, three years? Yeah, it's loved by experience. It's basically the idea is that you standardize on these interfaces. I think this is great that after all this 30, 40 years of learning on OSS, BSS systems and EMSs and all that, everybody has come together and said that let's define the interfaces between systems. Let's not just say that, put everything and we'll keep putting plug-ins or putting things together on the message buses. So I think your comment is very valid. Great. Thank you. So maybe just a follow-on question there. Let's see, I've been following some work in the IETF and they're there defining these Yang models and it allows you to talk to the device over NetConf and it's kind of that standard type of interface where you're not standardizing an exact API. It's more of a model. The content you pass is not standardized. How you talk to those devices is standardized and the models can be fared into. So one of the things that we didn't talk about is the southbound adaptation that we are talking about is based on such a device model that we have built a platform that takes the device models and supports NetConf. But at the same time, it also supports CLI and whatever other things that you have because that's the physical reality. That's the reality, exactly. And I mean, we actually are going through a real deployment case where we do support NetConf and CLI, so. Yeah, because that approach looks very promising to me. I just want, do you see any problems with that or is that, I mean, you agree? That's kind of. No, we agree. As long as people don't go in 10 different directions then I think. Hopefully the whole industry merges in that direction. Yeah, exactly. Thank you. Any other questions? Awesome. Thank you very much for joining us. Thank you all. Thank you.