Knowledge aggregation for GAN-based anomaly detectors

Systems, methods, and computer-readable media for distributing machine learning. In some examples, a first GAN model is deployed to a first network edge device and a second GAN model is deployed to a second network edge device. A generator of the first GAN model can be trained using real telemetry data of a first computing node and a generator of the second GAN model can be trained using real telemetry data of a second IoT device. The generator of the first GAN model and the generator of the second GAN model can be received. Additionally, a unified generator of a unified GAN model can be trained using the generator of the first GAN model and the generator of the second GAN model. Subsequently, the unified GAN model can be deployed to a third computing node for monitoring operation of the third IoT device.

TECHNICAL FIELD

The present technology pertains to distributing machine learning for performing network monitoring to network edge devices, and in particular to distributing generative adversarial network (GAN) model training to network edge devices for computing node, e.g. Internet of Things (IoT) device, network monitoring.

BACKGROUND

Typical machine learning involves a large number of computations that consume a large number of computational resources. When machine learning is applied to monitor large scale networks, immense amounts of computational resources are utilized. Specifically, as cheaper and more attainable computing nodes, e.g. IoT devices, are more widely adopted, networks continue to grow in size and complexity. In turn, this makes utilizing machine learning to monitor computing nodes in such networks difficult as a result of the large number of computational resources needed to actually monitor the computing nodes using machine learning.

Further, machine learning is typically applied to monitor networks from a centralized location or a centralized computational resource group, e.g. the cloud. As discussed previously, monitoring complex networks through machine learning requires large numbers of computational resources, making centralized implementation of network monitoring using machine learning extremely challenging. For example, the overhead of moving large amounts of data needed to monitor networks centrally using machine learning is vast making such implementation infeasible. There therefore exist needs for systems and methods of distributing computational resources for performing network monitoring using machine learning away from a central region. Specifically, there exist needs for distributing network monitoring through machine learning to computational resources at the edges of a network.

Additionally, telemetry data from computing nodes is typically used to monitor networks using machine learning. This is problematic when the networks are monitored from a centralized location. In particular, the telemetry data is sent from the computing nodes away from the edge of the network, potentially exposing the telemetry data. This presents security concerns that often preclude device owners from sharing telemetry data with outside parties. In turn, this makes applying machine learning to monitor networks problematic, as often times monitoring networks using machine learning is accomplished with telemetry data describing device behavior that is generated at or near the devices. There therefore exist needs for systems and methods of sending data describing computing node behavior away from a network edge, e.g. a LAN, without actually exposing telemetry data of the computing nodes.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

A method can include deploying a first GAN model to a first network edge device and deploying a second GAN model to a second network edge device. A generator of the first GAN model can be trained using real telemetry data of a first computing node and a generator of the second GAN model can be trained using real telemetry data of a second computing node. The method can also include receiving, from the first network edge device, the generator of the first GAN model and receiving, from the second network edge device, the generator of the second GAN model. Additionally, the method can include training a unified generator of a unified GAN model using the generator of the first GAN model and the generator of the second GAN model. The method can include deploying the unified GAN model to a third computing node for monitoring operations of the third computing node.

A system can include one or more processors and at least one computer-readable storage medium storing instructions which, when executed by the one or more processors, cause the one or more processors to deploy a first GAN model to a first network edge device and a second GAN model to a second network edge device. A generator of the first GAN model can be trained using real telemetry data of a first computing node and a generator of the second GAN model can be trained using real telemetry data of a second computing node. The instructions can also cause the one or more processors to receive, from the first network edge device, the generator of the first GAN model and receive, from the second network edge device, the generator of the second GAN model. Further, the instructions can cause the one or more processors to train a unified generator of a unified GAN model using the generator of the first GAN model and the generator of the second GAN model.

A non-transitory computer-readable storage medium having stored therein instructions which, when executed by a processor, cause the processor to deploy a first GAN model to a first network edge device and a second GAN model to a second network edge device. A generator of the first GAN model can be trained using real telemetry data of a first IoT device and a generator of the second GAN model can be trained using real telemetry data of a second IoT device. The instructions can cause the processor to receive, from the first network edge device, the generator of the first GAN model and receive, from the second network edge device, the generator of the second GAN model. Further, the instructions can cause the processor to train a unified generator of a unified GAN model using the generator of the first GAN model and the generator of the second GAN model. The instructions can also cause the processor to deploy the unified GAN model to a third IoT device for detecting anomalies during operation of the third IoT device.

EXAMPLE EMBODIMENTS

The disclosed technology addresses the need in the art for distributing network monitoring through machine learning to edges of a network. Additionally, the disclosed technology address the need in the art for performing network monitoring of computing nodes using machine learning without actually exposing telemetry data of the computing nodes outside of a network edge. The present technology involves system, methods, and computer-readable media for distributing network monitoring through machine learning to edges of a network. Additionally, the present technology involves systems, methods, and computer-readable media for performing network monitoring of computing nodes without exposing telemetry data of the computing nodes outside of a network edge.

A description of network environments and architectures for network data access and services, as illustrated inFIGS. 1A, 1B, 2A, 2Bis first disclosed herein. A discussion of systems, methods, and computer-readable medium for distributing machine learning to network edge devices, as shown inFIGS. 3-8, will then follow. The discussion then concludes with a brief description of example devices, as illustrated inFIGS. 9 and 10. These variations shall be described herein as the various embodiments are set forth. The disclosure now turns toFIG. 1A.

FIG. 1Aillustrates a diagram of an example cloud computing architecture100. The architecture can include a cloud102. The cloud102can be used to form part of a TCP connection or otherwise be accessed through the TCP connection. Specifically, the cloud102can include an initiator or a receiver of a TCP connection and be utilized by the initiator or the receiver to transmit and/or receive data through the TCP connection. The cloud102can include one or more private clouds, public clouds, and/or hybrid clouds. Moreover, the cloud102can include cloud elements104-114. The cloud elements104-114can include, for example, servers104, virtual machines (VMs)106, one or more software platforms108, applications or services110, software containers112, and infrastructure nodes114. The infrastructure nodes114can include various types of nodes, such as compute nodes, storage nodes, network nodes, management systems, etc.

The cloud102can provide various cloud computing services via the cloud elements104-114, such as software as a service (SaaS) (e.g., collaboration services, email services, enterprise resource planning services, content services, communication services, etc.), infrastructure as a service (IaaS) (e.g., security services, networking services, systems management services, etc.), platform as a service (PaaS) (e.g., web services, streaming services, application development services, etc.), and other types of services such as desktop as a service (DaaS), information technology management as a service (ITaaS), managed software as a service (MSaaS), mobile backend as a service (MBaaS), etc.

The client endpoints116can connect with the cloud102to obtain one or more specific services from the cloud102. The client endpoints116can communicate with elements104-114via one or more public networks (e.g., Internet), private networks, and/or hybrid networks (e.g., virtual private network). The client endpoints116can include any device with networking capabilities, such as a laptop computer, a tablet computer, a server, a desktop computer, a smartphone, a network device (e.g., an access point, a router, a switch, etc.), a smart television, a smart car, a sensor, a GPS device, a game system, a smart wearable object (e.g., smartwatch, etc.), a consumer object (e.g., Internet refrigerator, smart lighting system, etc.), a city or transportation system (e.g., traffic control, toll collection system, etc.), an internet of things (IoT) device, a camera, a network printer, a transportation system (e.g., airplane, train, motorcycle, boat, etc.), or any smart or connected object (e.g., smart home, smart building, smart retail, smart glasses, etc.), and so forth.

FIG. 1Billustrates a diagram of an example fog computing architecture150. The fog computing architecture can be used to form part of a TCP connection or otherwise be accessed through the TCP connection. Specifically, the fog computing architecture can include an initiator or a receiver of a TCP connection and be utilized by the initiator or the receiver to transmit and/or receive data through the TCP connection. The fog computing architecture150can include the cloud layer154, which includes the cloud102and any other cloud system or environment, and the fog layer156, which includes fog nodes162. The client endpoints116can communicate with the cloud layer154and/or the fog layer156. The architecture150can include one or more communication links152between the cloud layer154, the fog layer156, and the client endpoints116. Communications can flow up to the cloud layer154and/or down to the client endpoints116.

The fog layer156or “the fog” provides the computation, storage and networking capabilities of traditional cloud networks, but closer to the endpoints. The fog can thus extend the cloud102to be closer to the client endpoints116. The fog nodes162can be the physical implementation of fog networks. Moreover, the fog nodes162can provide local or regional services and/or connectivity to the client endpoints116. As a result, traffic and/or data can be offloaded from the cloud102to the fog layer156(e.g., via fog nodes162). The fog layer156can thus provide faster services and/or connectivity to the client endpoints116, with lower latency, as well as other advantages such as security benefits from keeping the data inside the local or regional network(s).

The fog nodes162can include any networked computing devices, such as servers, switches, routers, controllers, cameras, access points, gateways, etc. Moreover, the fog nodes162can be deployed anywhere with a network connection, such as a factory floor, a power pole, alongside a railway track, in a vehicle, on an oil rig, in an airport, on an aircraft, in a shopping center, in a hospital, in a park, in a parking garage, in a library, etc.

In some configurations, one or more fog nodes162can be deployed within fog instances158,160. The fog instances158,158can be local or regional clouds or networks. For example, the fog instances156,158can be a regional cloud or data center, a local area network, a network of fog nodes162, etc. In some configurations, one or more fog nodes162can be deployed within a network, or as standalone or individual nodes, for example. Moreover, one or more of the fog nodes162can be interconnected with each other via links164in various topologies, including star, ring, mesh or hierarchical arrangements, for example.

In some cases, one or more fog nodes162can be mobile fog nodes. The mobile fog nodes can move to different geographic locations, logical locations or networks, and/or fog instances while maintaining connectivity with the cloud layer154and/or the endpoints116. For example, a particular fog node can be placed in a vehicle, such as an aircraft or train, which can travel from one geographic location and/or logical location to a different geographic location and/or logical location. In this example, the particular fog node may connect to a particular physical and/or logical connection point with the cloud154while located at the starting location and switch to a different physical and/or logical connection point with the cloud154while located at the destination location. The particular fog node can thus move within particular clouds and/or fog instances and, therefore, serve endpoints from different locations at different times.

FIG. 2Aillustrates a diagram of an example Network Environment200, such as a data center. The Network Environment200can be used to support a TCP connection for exchanging data between an initiator and a receiver. In some cases, the Network Environment200can include a data center, which can support and/or host the cloud102. The Network Environment200can include a Fabric220which can represent the physical layer or infrastructure (e.g., underlay) of the Network Environment200. Fabric220can include Spines202(e.g., spine routers or switches) and Leafs204(e.g., leaf routers or switches) which can be interconnected for routing or switching traffic in the Fabric220. Spines202can interconnect Leafs204in the Fabric220, and Leafs204can connect the Fabric220to an overlay or logical portion of the Network Environment200, which can include application services, servers, virtual machines, containers, endpoints, etc. Thus, network connectivity in the Fabric220can flow from Spines202to Leafs204, and vice versa. The interconnections between Leafs204and Spines202can be redundant (e.g., multiple interconnections) to avoid a failure in routing. In some embodiments, Leafs204and Spines202can be fully connected, such that any given Leaf is connected to each of the Spines202, and any given Spine is connected to each of the Leafs204. Leafs204can be, for example, top-of-rack (“ToR”) switches, aggregation switches, gateways, ingress and/or egress switches, provider edge devices, and/or any other type of routing or switching device.

Leafs204can be responsible for routing and/or bridging tenant or customer packets and applying network policies or rules. Network policies and rules can be driven by one or more Controllers216, and/or implemented or enforced by one or more devices, such as Leafs204. Leafs204can connect other elements to the Fabric220. For example, Leafs204can connect Servers206, Hypervisors208, Virtual Machines (VMs)210, Applications212, Network Device214, etc., with Fabric220. Such elements can reside in one or more logical or virtual layers or networks, such as an overlay network. In some cases, Leafs204can encapsulate and decapsulate packets to and from such elements (e.g., Servers206) in order to enable communications throughout Network Environment200and Fabric220. Leafs204can also provide any other devices, services, tenants, or workloads with access to Fabric220. In some cases, Servers206connected to Leafs204can similarly encapsulate and decapsulate packets to and from Leafs204. For example, Servers206can include one or more virtual switches or routers or tunnel endpoints for tunneling packets between an overlay or logical layer hosted by, or connected to, Servers206and an underlay layer represented by Fabric220and accessed via Leafs204.

Applications212can include software applications, services, containers, appliances, functions, service chains, etc. For example, Applications212can include a firewall, a database, a CDN server, an IDS/IPS, a deep packet inspection service, a message router, a virtual switch, etc. An application from Applications212can be distributed, chained, or hosted by multiple endpoints (e.g., Servers206, VMs210, etc.), or may run or execute entirely from a single endpoint.

VMs210can be virtual machines hosted by Hypervisors208or virtual machine managers running on Servers206. VMs210can include workloads running on a guest operating system on a respective server. Hypervisors208can provide a layer of software, firmware, and/or hardware that creates, manages, and/or runs the VMs210. Hypervisors208can allow VMs210to share hardware resources on Servers206, and the hardware resources on Servers206to appear as multiple, separate hardware platforms. Moreover, Hypervisors208on Servers206can host one or more VMs210.

In some cases, VMs210and/or Hypervisors208can be migrated to other Servers206. Servers206can similarly be migrated to other locations in Network Environment200. For example, a server connected to a specific leaf can be changed to connect to a different or additional leaf. Such configuration or deployment changes can involve modifications to settings, configurations and policies that are applied to the resources being migrated as well as other network components.

In some cases, one or more Servers206, Hypervisors208, and/or VMs210can represent or reside in a tenant or customer space. Tenant space can include workloads, services, applications, devices, networks, and/or resources that are associated with one or more clients or subscribers. Accordingly, traffic in Network Environment200can be routed based on specific tenant policies, spaces, agreements, configurations, etc. Moreover, addressing can vary between one or more tenants. In some configurations, tenant spaces can be divided into logical segments and/or networks and separated from logical segments and/or networks associated with other tenants. Addressing, policy, security and configuration information between tenants can be managed by Controllers216, Servers206, Leafs204, etc.

Configurations in Network Environment200can be implemented at a logical level, a hardware level (e.g., physical), and/or both. For example, configurations can be implemented at a logical and/or hardware level based on endpoint or resource attributes, such as endpoint types and/or application groups or profiles, through a software-defined network (SDN) framework (e.g., Application-Centric Infrastructure (ACI) or VMWARE NSX). To illustrate, one or more administrators can define configurations at a logical level (e.g., application or software level) through Controllers216, which can implement or propagate such configurations through Network Environment200. In some examples, Controllers216can be Application Policy Infrastructure Controllers (APICs) in an ACI framework. In other examples, Controllers216can be one or more management components for associated with other SDN solutions, such as NSX Managers.

Such configurations can define rules, policies, priorities, protocols, attributes, objects, etc., for routing and/or classifying traffic in Network Environment200. For example, such configurations can define attributes and objects for classifying and processing traffic based on Endpoint Groups (EPGs), Security Groups (SGs), VM types, bridge domains (BDs), virtual routing and forwarding instances (VRFs), tenants, priorities, firewall rules, etc. Other example network objects and configurations are further described below. Traffic policies and rules can be enforced based on tags, attributes, or other characteristics of the traffic, such as protocols associated with the traffic, EPGs associated with the traffic, SGs associated with the traffic, network address information associated with the traffic, etc. Such policies and rules can be enforced by one or more elements in Network Environment200, such as Leafs204, Servers206, Hypervisors208, Controllers216, etc. As previously explained, Network Environment200can be configured according to one or more particular software-defined network (SDN) solutions, such as CISCO ACI or VMWARE NSX. These example SDN solutions are briefly described below.

ACI can provide an application-centric or policy-based solution through scalable distributed enforcement. ACI supports integration of physical and virtual environments under a declarative configuration model for networks, servers, services, security, requirements, etc. For example, the ACI framework implements EPGs, which can include a collection of endpoints or applications that share common configuration requirements, such as security, QoS, services, etc. Endpoints can be virtual/logical or physical devices, such as VMs, containers, hosts, or physical servers that are connected to Network Environment200. Endpoints can have one or more attributes such as a VM name, guest OS name, a security tag, application profile, etc. Application configurations can be applied between EPGs, instead of endpoints directly, in the form of contracts. Leafs204can classify incoming traffic into different EPGs. The classification can be based on, for example, a network segment identifier such as a VLAN ID, VXLAN Network Identifier (VNID), NVGRE Virtual Subnet Identifier (VSID), MAC address, IP address, etc.

In some cases, classification in the ACI infrastructure can be implemented by Application Virtual Switches (AVS), which can run on a host, such as a server or switch. For example, an AVS can classify traffic based on specified attributes, and tag packets of different attribute EPGs with different identifiers, such as network segment identifiers (e.g., VLAN ID). Finally, Leafs204can tie packets with their attribute EPGs based on their identifiers and enforce policies, which can be implemented and/or managed by one or more Controllers216. Leaf204can classify to which EPG the traffic from a host belongs and enforce policies accordingly.

Another example SDN solution is based on VMWARE NSX. With VMWARE NSX, hosts can run a distributed firewall (DFW) which can classify and process traffic. Consider a case where three types of VMs, namely, application, database and web VMs, are put into a single layer-2 network segment. Traffic protection can be provided within the network segment based on the VM type. For example, HTTP traffic can be allowed among web VMs, and disallowed between a web VM and an application or database VM. To classify traffic and implement policies, VMWARE NSX can implement security groups, which can be used to group the specific VMs (e.g., web VMs, application VMs, database VMs). DFW rules can be configured to implement policies for the specific security groups. To illustrate, in the context of the previous example, DFW rules can be configured to block HTTP traffic between web, application, and database security groups.

Returning now toFIG. 2A, Network Environment200can deploy different hosts via Leafs204, Servers206, Hypervisors208, VMs210, Applications212, and Controllers216, such as VMWARE ESXi hosts, WINDOWS HYPER-V hosts, bare metal physical hosts, etc. Network Environment200may interoperate with a variety of Hypervisors208, Servers206(e.g., physical and/or virtual servers), SDN orchestration platforms, etc. Network Environment200may implement a declarative model to allow its integration with application design and holistic network policy.

Controllers216can provide centralized access to fabric information, application configuration, resource configuration, application-level configuration modeling for a software-defined network (SDN) infrastructure, integration with management systems or servers, etc. Controllers216can form a control plane that interfaces with an application plane via northbound APIs and a data plane via southbound APIs.

As previously noted, Controllers216can define and manage application-level model(s) for configurations in Network Environment200. In some cases, application or device configurations can also be managed and/or defined by other components in the network. For example, a hypervisor or virtual appliance, such as a VM or container, can run a server or management tool to manage software and services in Network Environment200, including configurations and settings for virtual appliances.

As illustrated above, Network Environment200can include one or more different types of SDN solutions, hosts, etc. For the sake of clarity and explanation purposes, various examples in the disclosure will be described with reference to an ACI framework, and Controllers216may be interchangeably referenced as controllers, APICs, or APIC controllers. However, it should be noted that the technologies and concepts herein are not limited to ACI solutions and may be implemented in other architectures and scenarios, including other SDN solutions as well as other types of networks which may not deploy an SDN solution.

Further, as referenced herein, the term “hosts” can refer to Servers206(e.g., physical or logical), Hypervisors208, VMs210, containers (e.g., Applications212), etc., and can run or include any type of server or application solution. Non-limiting examples of “hosts” can include virtual switches or routers, such as distributed virtual switches (DVS), application virtual switches (AVS), vector packet processing (VPP) switches; VCENTER and NSX MANAGERS; bare metal physical hosts; HYPER-V hosts; VMs; DOCKER Containers; etc.

FIG. 2Billustrates another example of Network Environment200. In this example, Network Environment200includes Endpoints222connected to Leafs204in Fabric220. Endpoints222can be physical and/or logical or virtual entities, such as servers, clients, VMs, hypervisors, software containers, applications, resources, network devices, workloads, etc. For example, an Endpoint222can be an object that represents a physical device (e.g., server, client, switch, etc.), an application (e.g., web application, database application, etc.), a logical or virtual resource (e.g., a virtual switch, a virtual service appliance, a virtualized network function (VNF), a VM, a service chain, etc.), a container running a software resource (e.g., an application, an appliance, a VNF, a service chain, etc.), storage, a workload or workload engine, etc. Endpoints122can have an address (e.g., an identity), a location (e.g., host, network segment, virtual routing and forwarding (VRF) instance, domain, etc.), one or more attributes (e.g., name, type, version, patch level, OS name, OS type, etc.), a tag (e.g., security tag), a profile, etc.

Endpoints222can be associated with respective Logical Groups218. Logical Groups218can be logical entities containing endpoints (physical and/or logical or virtual) grouped together according to one or more attributes, such as endpoint type (e.g., VM type, workload type, application type, etc.), one or more requirements (e.g., policy requirements, security requirements, QoS requirements, customer requirements, resource requirements, etc.), a resource name (e.g., VM name, application name, etc.), a profile, platform or operating system (OS) characteristics (e.g., OS type or name including guest and/or host OS, etc.), an associated network or tenant, one or more policies, a tag, etc. For example, a logical group can be an object representing a collection of endpoints grouped together. To illustrate, Logical Group 1 can contain client endpoints, Logical Group 2 can contain web server endpoints, Logical Group 3 can contain application server endpoints, Logical Group N can contain database server endpoints, etc. In some examples, Logical Groups218are EPGs in an ACI environment and/or other logical groups (e.g., SGs) in another SDN environment.

Traffic to and/or from Endpoints222can be classified, processed, managed, etc., based Logical Groups218. For example, Logical Groups218can be used to classify traffic to or from Endpoints222, apply policies to traffic to or from Endpoints222, define relationships between Endpoints222, define roles of Endpoints222(e.g., whether an endpoint consumes or provides a service, etc.), apply rules to traffic to or from Endpoints222, apply filters or access control lists (ACLs) to traffic to or from Endpoints222, define communication paths for traffic to or from Endpoints222, enforce requirements associated with Endpoints222, implement security and other configurations associated with Endpoints222, etc.

In an ACI environment, Logical Groups218can be EPGs used to define contracts in the ACI. Contracts can include rules specifying what and how communications between EPGs take place. For example, a contract can define what provides a service, what consumes a service, and what policy objects are related to that consumption relationship. A contract can include a policy that defines the communication path and all related elements of a communication or relationship between endpoints or EPGs. For example, a Web EPG can provide a service that a Client EPG consumes, and that consumption can be subject to a filter (ACL) and a service graph that includes one or more services, such as firewall inspection services and server load balancing.

Typical machine learning involves a large number of computations that consume a large number of computational resources. When machine learning is applied to monitor large scale networks, immense amounts of computational resources are utilized. Specifically, as computing nodes are more widely adopted, networks continue to grow in size and complexity. In turn, this makes utilizing machine learning to monitor computing nodes in such networks difficult as a result of the large number of computational resources needed to actually monitor the computing nodes using machine learning.

Further, machine learning is typically applied to monitor networks from a centralized location or a centralized computational resource group, e.g. the cloud. As discussed previously, monitoring complex networks through machine learning requires large numbers of computational resources, making centralized implementation of network monitoring using machine learning extremely challenging. For example, the overhead of moving large amounts of data needed to monitor networks centrally using machine learning is vast making such implementation infeasible. There therefore exist needs for systems and methods of distributing computational resources for performing network monitoring using machine learning away from a central region. Specifically, there exist needs for distributing network monitoring through machine learning to computational resources at the edges of a network.

Additionally, telemetry data from computing nodes, e.g. IoT devices, is typically used to monitor networks using machine learning. This is problematic when the networks are monitored from a centralized location. In particular, the telemetry data is sent from the computing nodes away from the edge of the network, potentially exposing the telemetry data. This presents security concerns that often preclude device owners from sharing telemetry data with outside parties. In turn, this makes applying machine learning to monitor networks problematic, as often times monitoring networks using machine learning is accomplished with telemetry data describing device behavior that is generated at or near the devices. There therefore exist needs for systems and methods of sending data describing computing node behavior away from a network edge, e.g. a LAN, without actually exposing telemetry data of the computing node.

The present includes systems, methods, and computer-readable mediums for distributing machine learning for performing network monitoring to network edge devices. A first GAN model can be pushed to a first network edge device where a generator of the first GAN model can be trained using real telemetry data of a first computing node. Further a second GAN model can be pushed to a second network edge device where a generator of the second GAN model can be trained using real telemetry data of a second computing node. The generator of the first GAN model can be received from the first network edge device and the generator of the second GAN model can be received from the second network edge device. A unified generator of a unified GAN model can be trained using the generator of the first GAN model and the generator of the second GAN model. Subsequently, the unified GAN model can be deployed to a third computing node for monitoring operation of the third computing node.

FIG. 3illustrates an example environment300for distributing machine learning to edges of a network for monitoring network devices in the network. The example environment300shown inFIG. 3includes a first network edge device302and a second edge network edge device304. The example environment300also includes a unified GAN training system306. The environment300, shown inFIG. 3, can be implemented using one or a combination of the environments and architectures shown inFIGS. 1-2. For example, the unified GAN training system306can be implemented in an applicable cloud computing architecture, such as the cloud computing architecture100shown inFIG. 1A. In another example, either or both the first network edge device302and the second network edge device304can be implemented in an applicable fog computing architecture, such as the fog computing architecture150shown inFIG. 1B.

A network edge device, as used herein, can include an applicable device for providing an entry point into a network. Specifically, a network edge device can include a client device utilized to grant/obtain network service access to a WAN through LAN. For example, a network edge device can include a computing node configured to access network services through the Internet. Further, a network edge device can include a client device/computing node utilized by a user to access network service over the Internet. Additionally, a network edge device can include a device within a WAN that is configured to provide access to the WAN.

A computing node can include an applicable device for performing computational functions, such as a device configured to operate according to the computing system architecture900shown inFIG. 9and the network device1000shown inFIG. 10. A computing node, as used herein, can include an IoT device. An IoT device, as used herein, includes an applicable device for sending and/or receiving data over a network. Specifically, an IoT device can include an applicable device for accessing network services through a network, e.g. the Internet. For example, an IoT device can include a desktop computing device, a portable computing device, and other applicable devices that are configured to communicate through a network, e.g. to interview with an external or remote environment.

The first network edge device302and the second network edge device304can be configured to receive GAN models. Specifically, the first network edge device302and the second network edge device304can respectively receive a first GAN model308and a second GAN model310. The corresponding GAN models308and310received at the first network edge device302and the second network edge can be utilized, as will be discussed in greater detail later, to monitor network performance of network devices in a network environment. Specifically, the corresponding GAN models308and310can be utilized to monitor network performance at network edge devices, e.g. computing nodes, in a network. While reference is made to GAN models throughout this description, in various embodiments, an applicable machine learning model can be distributed and used for monitoring performance of network devices in a network.

The unified GAN training system306can function to deploy the first GAN model308to the first network edge device302and the second GAN model310to the second network edge device304. Specifically, the unified GAN training system306can be implemented remote from the first network edge device302and the second network edge device304away from an edge of a network, e.g. in a cloud computing architecture. Subsequently, the unified GAN training system306can deploy, from a remote network location where the unified GAN training system306is implemented, the first GAN model308to the first network edge device302and the second GAN model310to the second network edge device304.

The first GAN model308can be trained at the first network edge device302to create a generator of the first GAN model308. Additionally, the second GAN model310can be trained at the second network edge device304to create a generator of the second GAN model310. As will be discussed in greater detail later, the generator of the first GAN model308and the generator of the second GAN model310can ultimately be used in monitoring operation of network devices, e.g. network edge devices, in a network.

The first GAN model308and the second GAN model310can be trained at the corresponding first network edge device302and the second network edge device304using real telemetry data of computing nodes, e.g. IoT devices. Telemetry data includes applicable data related to operation of computing nodes, e.g. operation in a network environment. For example, if a computing node is a thermostat, then telemetry data can include measured temperatures at the thermostat over time. The first GAN model308and the second GAN model310can be trained on real telemetry from different computing nodes. For example, the first GAN model308can be trained on real telemetry data from a first computing node, while the second GAN model310can be trained on real telemetry data from a second computing node different from the first computing node.

The first network edge device302can be the same device that generates real telemetry data used to train the first GAN model308. For example, the first network edge device302can be a computing node that generates real telemetry data for training the first GAN model308at the computing node. Additionally, the second network edge device304can be the same device that generates real telemetry data used to train the second GAN model310. For example, the second network edge device304can be a computing node that generates real telemetry data for training the second GAN model310at the second computing node.

Further, the first network edge device302can be a different device from a device that generates real telemetry data used to train the first GAN model308at the first network edge device302. For example, the first network edge device302can be an access point configured to receive telemetry data from a separate computing node that is used to train the first GAN model308at the access point. Similarly, the second network edge device304can be a different device from a device that generates real telemetry data used to train the second GAN model310at the second network edge device304. For example, the second network edge device302can be a router in an Ethernet backhaul of a LAN configured to receive telemetry data from a separate computing node that is used to train the second GAN model310at the router.

All or portions of the first GAN model308and the second GAN model310can be different. Specifically, the first GAN model308and the second GAN model310can differ based on characteristics/environmental characteristics of the devices used to train the models308and310. In turn, this can facilitate increased accuracy in training the first GAN model308and the second GAN model310, as the models can be tailored to the specific devices used to train the GAN models308and310. However, this can preclude reusing the trained first GAN model308and the trained second GAN model310on different devices, even if the devices are the same type as the first network edge device302and the second network edge device304. As will be discussed in greater detail later, a unified GAN model can be generated from the differing first and second GAN models308and310to eliminate, at least in part, the need for reusing the trained first GAN model308and the trained second GAN model310on the different network edge devices.

The first GAN model308and the second GAN model310can be trained according to an applicable GAN model to create a generator of the corresponding first and second GAN models308and310. Specifically,FIG. 4illustrates a flow400for training an example GAN model402. The flow400shown inFIG. 4can be used to train an applicable GAN model, such as the first GAN model308and the second GAN model310.

The GAN model402includes a generator (G1)404and a discriminator (D1)406. The input to the generator404is a random number generator Z that generates random/pseudo-random numbers and feeds these random numbers to the generator404. The generator404can then modify these random numbers to generate fake samples408that are fed to the discriminator406. Additionally, the discriminator406can receive real telemetry data410generated by a modeled device, e.g. IoT device, used to train the GAN model402.

The discriminator406can then compare the fake samples408received from the generator404with the real telemetry data410received from the modeled device. In comparing the fake samples408received from the generator404with the real telemetry data410, the discriminator406can determine, or otherwise attempt to determine, whether the received data is actually fake sample data or real telemetry data agnostic as to the source of the received data. Specifically, the discriminator406can attempt to identify the differences between the real telemetry data410and the fake samples408to attempt to separate the fake samples408from the real telemetry data410.

Simultaneously/semi-simultaneously, the generator404can learn a model of a state of the modeled device to attempt to fool the discriminator406into thinking the fake samples408are actually real telemetry data410of the modeled device. Specifically, the generator404can receive feedback from the discriminator406related to the discriminator406being tricked into thinking the fake samples408are actually in the real telemetry data410. For example, the discriminator406can provide feedback indicating the fake samples408that the discriminator406actually identified as fake data when compared to the real telemetry data410. In turn, the generator404can change how it modifies the random/pseudo random numbers generated by Z, e.g. model the actual behavior of the modeled device, to further try to trick the discriminator406

The loop of the discriminator406providing feedback to the generator404and the generator404further refining the fake samples408/modeling the actual behavior of the modeled device can continue until equilibrium is reached. Specifically, equilibrium can be reached when the discriminator406can no longer determine which of the fake samples408/a threshold number of the fake samples408provided by the generator404are actually fake samples when compared to the real telemetry data410.

The overall loop of the generator404providing the fake samples408to the discriminator406and the discriminator406comparing the fake samples408to the real telemetry data410can continue during operation of the device, even when equilibrium is reached. In turn this can allow for the generator404to model the behavior of the modeled device when the actual behavior of the modeled device changes. For example, when real telemetry data410of the modeled device changes, e.g. due to changed environmental/operating conditions of the modeled device, the generator404can further continue to adjust itself/model the device, until equilibrium is reached again.

Returning back to the environment300shown inFIG. 3, the first network edge device302can provide a generator of the first GAN model308back to the unified GAN training system306. Similarly, the second network edge device304can provide a generator of the second GAN model310to the unified GAN training system306. The unified GAN training system306, as discussed previously, can be implemented remote from the first network edge device302and the second network edge device304and subsequently receive the generator of the first GAN model308and the generator of the second GAN model310remote from the first network edge device302and the second network edge device304.

In sending the generator of the first GAN model308to the unified GAN training system306, the first network edge device302can refrain from sending the telemetry data of a modeled computing node used to train the first GAN model308to the unified GAN training system306. Similarly, in sending the generator of the second GAN model310to the unified GAN training system306, the second network edge device304can refrain from sending the telemetry data of a modeled computing node used to train the second GAN model310to the unified GAN training system306. This can eliminate or reduce security concerns associated with exposing telemetry data from computing nodes away from network edges.

Specifically and as discussed previously, telemetry data from computing nodes is typically used to monitor networks using machine learning. This is problematic when the networks are monitored from a centralized location. In particular, the telemetry data is typically sent from the computing node away from the edge of the network, potentially exposing the telemetry data, thereby presenting security concerns that often preclude device owners from sharing telemetry data with outside parties. In turn, this makes applying machine learning to monitor networks problematic, as often times monitoring networks using machine learning is accomplished with telemetry data describing device behavior that is generated at or near the devices. By sending the generator of the first GAN model308and the generator of the second GAN model310instead of the telemetry data actually used to train these generators, the security risks posed by sending the telemetry data away from the edge of the network are reduced or otherwise eliminated. Specifically, an attacker may be able to access the generators but still can't perform adversarial attacks on discriminators of the GAN models308and310.

The first network edge device302and the second network edge device304can provide the corresponding generator of the first GAN model308and the generator of the second GAN model310according to set intervals. For example, the first network edge device302can provide a continuously trained generator of the first GAN model308to the unified GAN training system306every ten minutes.

Further, the first network edge device302and the second network edge device304can provide the corresponding generator of the first GAN model308and the generator of the second GAN model310in response to triggering events for pushing the generators from the first and second network edge devices302and304. For example, the first network edge device302can push the generator of the first GAN model308to the unified GAN training system306in response to a triggering event. Further in the example, the second network edge device304can push the generator of the second GAN model310to the unified GAN training system306in response to a triggering event. The triggering events for pushing of the corresponding generators from the first network edge device302and the second network edge device304can be the same triggering event or different triggering events.

A triggering event for pushing a generator of a GAN model to the unified GAN training system306can depend on model parameters of the GAN model. Specifically, a generator of a GAN model can be pushed to the unified GAN training system306when model parameter values for training the GAN model deviate beyond a specific amount/threshold from previous model parameter values. For example, a GAN model can be trained on pressure data from a computing node. Further in the example, if the pressure data used to train the GAN model deviates beyond a threshold amount, e.g. two standard deviations, from previous pressure data used to train the GAN model, then the GAN model can be pushed to the unified GAN training system306.

FIG. 5shows a graph500of mapped values of model parameters for determining when to push a GAN model from a network edge device to an applicable destination, e.g. to the unified GAN training system306, according to a triggering event. The graph500includes mappings of first model parameter W1values and second model parameter W2values into a multidimensional space. Specifically, the first model parameter W1values and the second model parameter W2values at various training steps, e.g. at specific times in training the GAN model, are mapped into the multidimensional space. For example, if a computing node used to train a GAN model measures water temperature and water pressure flow, then measured water temperatures and water pressures, at various times corresponding to various training steps, can be mapped to a multidimensional space. Specifically, in the graph500shown inFIG. 5, W1can represent water temperature and W2can represent water pressure as model parameters of the GAN model. Accordingly, a water temperature measurement at a specific time can be mapped along the W1axis, and a water pressure measurement at the specific time can be mapped along the W2axis to map the values of the model parameters at a training step corresponding to the specific time.

In the graph500, at a first training step (t1)502, the values of the model parameters W1and W2are mapped into the multidimensional space. Similarly, at a second training step504, a third training step506, and a fourth training step508, the values of the model parameters W1and W2, corresponding to each training step, are mapped into the multidimensional space. As shown in the graph500, the values of the model parameters and corresponding mappings at the first training step502, the second training step504, the third training step506, and the fourth training step508, stay within a specific region510within the multidimensional space. The region510can be a threshold model parameter value region that is pre-defined or defined based on mappings of model parameter values to the multidimensional space during previous training steps. Specifically, the region510can represent a standard deviation amount of model parameter values during a group of training steps.

Further, in the graph500, at a fifth training step (t5)512, the values of the model parameters, corresponding to the mapping into the multidimensional space of the fifth training step512, falls outside of the region510. Specifically, the values of the model parameters at the fifth training step512fall outside of a standard deviation of values of the model parameters at the previous first, second, third, and fourth training steps502,504,506, and508. In turn, this large discrepancy between the values of the model parameters at the fifth training step512and the previous training steps502,504,506, and508can correspond to a triggering event for pushing the GAN model/generator from a network edge device, e.g. where the GAN model is trained. For example, in response to the mapping of the fifth training step512falling out of the region510, the generator of the GAN model can be pushed from the network edge device to an applicable system, such as the unified GAN training system306.

Pushing the GAN model/generator based on a comparison of mappings of model parameter values at different training steps can account for problems associated with pushing the GAN model/generator in response to falsely detected anomalies. Specifically, anomaly detection is plagued by high rates of false positives. One way to combat this problem is to utilize more accurate behavior and anomaly detection models that are trained on more diverse data. However, when a single device is being monitored and/or devices are being monitored on-premise, e.g. at the edge of the network, diversity in training data is often limited, thereby increasing the chances of false positive anomaly detections when training corresponding anomaly detection models. By pushing a GAN model/generator when significant changes in model parameter values are observed, e.g. more likely caused by true positive anomaly detections, the chances that the GAN model/generator will be pushed in response to false positive anomaly detections, e.g. minor fluctuations in model parameter values, are reduced.

Additionally, pushing the GAN model/generator based on a comparison of mappings of model parameter values at different training steps can reduce computational resources used by an overall network monitoring system. Specifically, networks incorporating computing nodes, e.g. IoT devices, often include a large number of monitored devices. Pulling GAN models/generators frequently for these computing nodes increases the amount of computational resources needed to process the GAN models/generators to unfeasible levels. Further, this also increases the length of aggregation cycles to the point where unified GAN models created from the pulled GAN models/generators are obsolete with respect to newly created telemetry data at the computing nodes. Pushing the GAN models/generators less frequently based on a comparison of mappings of model parameter values at different training steps, as opposed to pushing the models whenever minor fluctuations in model parameter values are observed, makes implementation of GAN-based network device monitoring in large networks more feasible.

Returning back to the environment300shown inFIG. 3, the unified GAN training system306functions to generate a unified GAN model312. The unified GAN model312, as will be discussed in greater detail later, can be deployed to other network edge devices, e.g. different network edge devices from the first network edge device302and the network edge device304, for purposes of detecting anomalies in device operation.

The unified GAN training system306can generate the unified GAN model312using the generator of the first GAN model308received from the first network edge device302and the generator of the second GAN model310received from the second network edge device304.FIG. 6illustrates a flow600by which generators for different GAN models can be combined to form a unified GAN model. The example flow600shown inFIG. 6can be utilized by the unified GAN training system306to generate the unified GAN model312.

In the flow600, a first generator602and a second generator604are received. The first generator602and the second generator604can be combined to form virtual telemetry data606of modeled computing nodes, e.g. IoT devices. The virtual telemetry data606is virtual because the generators602and604are not the actual telemetry data generated by the computing nodes, but instead are trained to replicate the telemetry data of the computing nodes through GAN models.

The first generator602is merged with the second generator604to form the virtual telemetry data606, despite the differences between the data in the first generator602and the data in the second generator604.FIGS. 7A and 7Billustrate data graphs700and702of two different generators combined to form virtual telemetry data for training a unified GAN model. In each data graph700and702, the data is mapped as values of packets per second (“PPS”) verses average queue length of a TX buffer (“Queue len”). In this example, device1, corresponding to data graph700, is set up in the environment with relatively low load, so a GAN model captures the state of having low PPS and a short queue as “normal”. Device2, corresponding to data graph702, however, is deployed in a different environment with a higher load. Both devices are of same type and could be used interchangeably, however the discrepancies in the data of the generators shown inFIGS. 7A and 7Bare due to the different environments in which the devices operate. Despite the discrepancies in the data, the data of the first device/generator can be aggregated with the data of the second device/generator to form a single group of aggregated virtual telemetry data. In turn, a unified GAN can be trained based on the aggregated virtual telemetry data despite the large differences in the data.

Returning back to the flow600shown inFIG. 6, the unified GAN model includes a unified GAN generator608and a unified GAN discriminator610. Similar to the flow400for training a GAN model shown inFIG. 4, the input to the unified GAN generator608is a random number generator Z that generates random/pseudo-random numbers and feeds these random numbers to the unified GAN generator608. The unified GAN generator608can then modify these random numbers to generate fake samples612that are fed to the unified GAN discriminator610. Additionally, the unified GAN discriminator610can receive the virtual telemetry data606generated by merging the first generator602and the second generator604.

The unified GAN discriminator610can then compare the fake samples612received from the unified GAN generator608with the virtual telemetry data606. In comparing the fake samples612received from the unified GAN generator608with the virtual telemetry data606, the unified GAN discriminator610can determine, or otherwise attempt to determine, whether the data is actually fake sample data or virtual telemetry data agnostic as to the source of the data. Specifically, the unified GAN discriminator610can attempt to identify the differences between the virtual telemetry data606and the fake samples612to attempt to separate the virtual telemetry data606from the fake samples612.

Simultaneously/semi-simultaneously, the unified GAN generator608can learn a model of a state of the devices modeled to create the first generator602and the second generator604to attempt to fool the unified GAN discriminator610into thinking the fake samples612are actually virtual telemetry data606of the first and second generators602and604. Specifically, the unified GAN generator608can receive feedback from the unified GAN discriminator610related to the unified GAN discriminator610being tricked into thinking the fake samples612are actually in the virtual telemetry data606. For example, the unified GAN discriminator610can provide feedback indicating the fake samples612that the unified GAN discriminator610actually identified as fake data when compared to the virtual telemetry data606. In turn, the unified GAN generator608can further try to trick the unified GAN discriminator610into thinking the fake samples612are actually the virtual telemetry data. Specifically, the unified GAN generator608can change how it modifies the random/pseudo random numbers generated by Z, e.g. model the behavior of the devices used to generate the first generator602and the second generator602, to further try to trick the unified GAN discriminator610.

The loop of the unified GAN discriminator610providing feedback to the unified GAN generator608and the unified GAN generator608further refining the fake sample data612can continue until equilibrium is reached. Specifically, equilibrium can be reached when the unified GAN discriminator610can no longer determine which of the fake samples612/a threshold number of the fake samples612provided by the unified GAN generator608are actually fake samples when compared to the virtual telemetry data606.

Returning back toFIG. 3, the environment includes a third network edge device314. The third network edge device314can be of the same device type as either or both the first network edge device302and the second network edge device304. For example, third network edge device314, the first network edge device302, and the second network edge device304can all be the same type of smart phone. Additionally, the third network edge device314can be of the same device type as a device modeled by either or both the first GAN model308and the second GAN model310.

The unified GAN training system306functions to deploy the unified GAN model312, e.g. trained according to the flow600shown inFIG. 6, to the third network edge device314. Subsequently, the unified GAN model312can be utilized to monitor network performance, e.g. by detecting anomalies in network operation of the third network edge device314. Further, the unified GAN model312can be utilized by the third network edge device314to monitor network performance of a device associated with the third network edge device314, e.g. by detecting anomalies in network operation of the device associated with the third network edge device314.

The overall flow discussed with respect to the environment300shown inFIG. 3can be repeated. Specifically, the first network edge device302and the second network edge device304can create updated generators of the first GAN model308and the second GAN model310using additional real telemetry data. Subsequently, the first network edge device302and the second network edge device304can send the updated generators of the first GAN model308and the second GAN model310to the unified GAN training system306. The unified GAN training system306can then use the updated generators of the first GAN model308and the second GAN model310to generate an updated unified GAN model312. The updated unified GAN model312can then be deployed to the third network edge device314for purposes of performing network monitoring, e.g. through anomaly detection.

FIG. 8illustrates a flowchart for an example method of distributing machine learning to a network edge for monitoring operation of devices in a network. The method shown inFIG. 8is provided by way of example, as there are a variety of ways to carry out the method. Additionally, while the example method is illustrated with a particular order of steps, those of ordinary skill in the art will appreciate thatFIG. 8and the modules shown therein can be executed in any order and can include fewer or more modules than illustrated.

Each module shown inFIG. 8represents one or more steps, processes, methods or routines in the method.

At step800, a first GAN model is deployed to a first network edge device. The first GAN model can be used to model behavior of the first network edge device or a device associated with the first network edge device, e.g. a computing node coupled to the first network edge device. Additionally, at step800, a second GAN model is deployed to a second network edge device. The second GAN model can be used to model behavior of the second network edge device or a device associated with the second network edge device.

At step802, the generator of the first GAN model and the generator of the second GAN model are received from the corresponding first network edge device and second network edge device. The generator of the first GAN model can be trained based on real telemetry data and the generator of the first GAN model can be transmitted without transmitting the real telemetry data used to train the generator. Similarly, the generator of the second GAN model can be trained based on real telemetry data and the generator of the second GAN model can be transmitted without transmitting the real telemetry data used to train the generator.

At step804, a unified generator of a unified GAN model is trained using the generator of the first GAN model and the generator of the second GAN model. The unified generator can be trained at an applicable system, such as the unified GAN training system306.

At step806, the unified GAN model is deployed to a third computing node, e.g. IoT device, for monitoring operation of the third computing node. Specifically, the unified GAN model can be deployed to the third computing node for detecting anomalies in the operation of the third computing node in a network environment.

The disclosure now turns toFIGS. 9 and 10, which illustrate example network devices and computing devices, such as switches, routers, load balancers, client devices, and so forth.

FIG. 9illustrates a computing system architecture900wherein the components of the system are in electrical communication with each other using a connection905, such as a bus. Exemplary system900includes a processing unit (CPU or processor)910and a system connection905that couples various system components including the system memory915, such as read only memory (ROM)920and random access memory (RAM)925, to the processor910. The system900can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor910. The system900can copy data from the memory915and/or the storage device930to the cache912for quick access by the processor910. In this way, the cache can provide a performance boost that avoids processor910delays while waiting for data. These and other modules can control or be configured to control the processor910to perform various actions. Other system memory915may be available for use as well. The memory915can include multiple different types of memory with different performance characteristics. The processor910can include any general purpose processor and a hardware or software service, such as service1932, service2934, and service3936stored in storage device930, configured to control the processor910as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor910may be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

Storage device930is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs)925, read only memory (ROM)920, and hybrids thereof.

The storage device930can include services932,934,936for controlling the processor910. Other hardware or software modules are contemplated. The storage device930can be connected to the system connection905. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor910, connection905, output device935, and so forth, to carry out the function.

FIG. 10illustrates an example network device1000suitable for performing switching, routing, load balancing, and other networking operations. Network device1000includes a central processing unit (CPU)1004, interfaces1002, and a bus1010(e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU1004is responsible for executing packet management, error detection, and/or routing functions. The CPU1004preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU1004may include one or more processors1008, such as a processor from the INTEL X86 family of microprocessors. In some cases, processor1008can be specially designed hardware for controlling the operations of network device1000. In some cases, a memory1006(e.g., non-volatile RAM, ROM, etc.) also forms part of CPU1004. However, there are many different ways in which memory could be coupled to the system.

Regardless of the network device's configuration, it may employ one or more memories or memory modules (including memory1006) configured to store program instructions for the general-purpose network operations and mechanisms for roaming, route optimization and routing functions described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc. Memory1006could also hold various software containers and virtualized execution environments and data.

The network device1000can also include an application-specific integrated circuit (ASIC), which can be configured to perform routing and/or switching operations. The ASIC can communicate with other components in the network device1000via the bus1010, to exchange data and signals and coordinate various types of operations by the network device1000, such as routing, switching, and/or data storage operations, for example.

Claim language reciting “at least one of” refers to at least one of a set and indicates that one member of the set or multiple members of the set satisfy the claim. For example, claim language reciting “at least one of A and B” means A, B, or A and B.