So let's talk about the work that we at Intel and our partners are doing to enable open service assurance. The open APIs and tools included in the [INAUDIBLE] based platform specification really provide the glue for parsing the rich telemetry provided by Intel platforms-- i.e. the hardware-- and the performance and event management information that's available from software-- now, that could be virtual machine managers, virtual VIMs, et cetera-- into a common framework such that systems such as network management, and analytics functions, MANO stacks, SDN controllers, other analytics tools can access that cemetery, understand it, and take action based on it. At Intel, we chose Collectd as the primary project for the collection of telemetry data from our platform. And we chose Collectd because it's very well-established in the industry, it's in use by many traditional network management tools, and it provides a very flexible and extensible plug-in model that enables you to easily extend it, and provide the ability to gather new data sources, and to publish northbound to a wide range of software components. So Intel server platforms include many valuable features which are important for enabling high-performing VMFs, things like Intel network interface cards, hardware accelerators for security and compression algorithms, called Intel Quick Assist Technology. And there are many CPU features, such as Intel Resource Director Technology, which gives the ability to closely monitor and allocate memory and cache resources to applications. Many of these components can provide a rich set of telemetry that could be used for monitoring purposes and detect faults, along with other platform metrics such as power and thermals. But the challenge is that many of these components have their own native collection interfaces, and so it's very complex to gather information from all of these sources. So with the work that Intel has done, and under the Intel infrastructure management technologies umbrella, we have provided a single interface, a unified way to gain access to the telemetry information that is available from all of these sources for a single interface. So in summary, if you can't measure, control the underlying platform resources, it will be very hard to measure, and control, and guarantee performance for services running on that infrastructure. So in this slide, we take a look at an example of how a properly-enabled platform can work with both traditional network management tools and work with newer MANO tools. So in this example, we'll talk about a system which is running two virtual machines. And let's imagine a scenario where one of those virtual machines is running a video streaming service. And we'll imagine that that video streaming service is running in virtual machine one. If the application running in virtual machine two takes a disproportionate amount of platform resources, it could potentially affect the performance of the video streaming application in VM1, which could result in poor experience, stuttering video for the end user. So what I want to demonstrate here is two paths to capture telemetry that indicates that that condition is under way. So we have the ability through Intel Resource Director Technology to capture telemetry related to cache utilization, rates for workloads running on the platform. We can pass that information into the Collectd project. And that data can then be passed up to a network management system perhaps using SNMP protocol. And then that system can alert an admin who could potentially manually take action or some automated action could be triggered within that traditional network management system. At the same time, the same telemetry is available and can be passed up into Collectd. That event can be passed up into a MANO, and NFV management and orchestration, NFV MANO stack via, for example, the telometer project in OpenStack. And then that MANO stack can initiate a policy that, for example, may require the noisy neighbor, the application running in virtual machine two that was causing the problem is moved to another platform, or is the resources available to that virtual machine are decreased to a point where the application with higher service level agreement, the video streaming application, returns to its expected performance level. So here, we see the same capability of taking resource director technology counters into Collectd and then through another plug-in can be applied both to traditional network management systems and to the emerging sets of MANO systems. And these two systems can coexist, and indeed can potentially cooperate and benefit from each other. So a broad ecosystem is emerging to address the service assurance challenge in NFV. And Intel is working in many of these projects to ensure that the telemetry available on our platform is exposed. Of course, Intel is heavily involved in the NFV infrastructure platform, as that's primarily where our hardware ingredients are used. But we also operate in many of the software projects to try to enable the industry in this area. We are working heavily within the OPNFV project on a project called Barometer. We're heavily engaged, of course, in projects such as DPDK, and Open vSwitch, and FDIO, as well as taking an active role in some of the open source management and orchestration projects, such as Open Source MANO and ONAP. A broad ecosystem consisting of traditional network management vendors, OSS and BSS vendors, and new MANO projects and vendors really need to come together to tackle this end-to-end short service assurance problem. And finally, of course, one of the great promises of this technology is the ability to move beyond the simple detection of a fault followed by some manually initiated fix to a situation where an issue can be understood and potentially fixed automatically. So we are seeing the emergence of artificial intelligence and machine learning techniques being applied to the service assurance problem. With machine learning, we should start to be able to detect patterns, and correlate data from multiple different subsystems, and really start to drive the ability to learn, and to predict, and to automate fixes potentially before they even really become an issue. So this really promises to be an exciting area of development over the coming years, and one that Intel will be seeking to participate in and accelerate through our work in open source projects and with our work with our partner ecosystem. [THEME MUSIC]
