Devices and methods for network data monitoring and extraction.

Abstract

This disclosure describes methods, devices, and systems for anomaly detection and policy enforcement. An exemplary network server includes a network interface component configured to receive network packets from a router device in real time. The network server also includes a data processing unit configured to extract packet metadata from network packets. The network server further includes a policy component configured to provide policy rules to the router device, which are generated based on an analysis of the packet metadata.

Description

Technical Field

[0001] Priority and Related Applications This application is a continuation of U.S. Patent Application No. 18 / 646,618, entitled "Devices and Methods for Network Data Monitoring and Extraction" (filed on April 25, 2024), and claims priority to the following: (1) U.S. Provisional Patent Application No. 63 / 498,361, entitled "Devices and Methods for Network Data Monitoring and Extraction" (filed on April 26, 2023), (2) U.S. Provisional Patent Application No. 63 / 498,363, entitled "Devices and Methods for Anomaly Detection" (filed on April 26, 2023), (3) U.S. Provisional Patent Application No. 63 / 498,413, entitled "Devices and Methods for Network Data Classification" (filed on April 26, 2023), and (4) U.S. Provisional Patent Application No. 63 / 498,417, entitled "Devices and Methods for Network Policy Enforcement" (filed on April 26, 2023).

[0002] This application generally relates to network data monitoring and extraction (including, but not limited to, systems and methods for anomaly detection and policy application).

Background Art

[0003] Current network operating systems provide telemetry data using standard protocols (e.g., netflow or sflow). This telemetry data can then be analyzed offline by a dedicated network analysis platform. The network analysis output can then be sent to a network management system or software-defined controller. The controller can then enforce policies using a management plane or protocol (e.g., border gateway protocol). These policies are predefined by the network administrator.

[0004] Alternatively, a dedicated device (e.g., a network intrusion prevention system) can be deployed inline with the network device. This device can perform the above functions based on statistical analysis of packet metadata. However, to prevent similar future events, it is necessary to generate new signatures after analyzing the network attack. These methods cannot provide sufficient protection against zero-day attacks or persistent targeted attacks in a preemptive or real-time manner.

[0005] The emergence of network isolation (vertical and horizontal) presents new challenges because of the presence of numerous closed-source third-party software components (e.g., embedded firmware and / or SDK software), as well as open-source components that together form routing or switching systems. Thus, multiple subcomponents exist that make the system vulnerable. Furthermore, increasing data network speeds are adding complexity to existing systems. [Overview of the project]

[0006] Therefore, there is a need for security systems and methods that enable the proactive detection and isolation of security threats (e.g., volumetric DDoS, protocol attacks, OSI data link, network, transport layer, and / or zero-day attacks) against network operating systems and their subsystems (e.g., control plane, data plane, and management plane) through real-time analysis of packet metadata.

[0007] This disclosure describes network components (e.g., traffic collector components, machine learning components, and policy components) that provide security protection against distributed denial of service (DDOS), protocol anomalies, zero-day attacks, and other software vulnerabilities and anomalies. The exemplary systems described herein collect logging, protocol, and / or packet metadata and create time-series profiles of network elements and network operations to form behavioral models. In this example, this model is used for anomaly detection and automatically generates mitigation policies. These policies may be transmitted to monitored network endpoints via the network over wire protocols. Policy agents within network elements may implement these policies in real time. The exemplary systems may be configured for anomaly detection (e.g., security and traffic engineering), root cause analysis (e.g., system failure analysis), predictive maintenance (e.g., predicting failures through automated mitigation of uptime), dynamic network optimization (e.g., optical, wireless, and packet networks), automation of network operations (e.g., traffic engineering and network routing operations), SLA assurance, trouble ticket classification, and / or churn prediction based on QoS metrics.

[0008] According to some embodiments, the anomaly mitigation method includes (i) obtaining metadata for multiple network packets, (ii) obtaining operational information corresponding to one or more network devices, (iii) detecting anomalies in the multiple network packets by analyzing the obtained metadata, (iv) generating policy rules without human intervention based on the detected anomalies, and (v) applying the policy rules to one or more network devices.

[0009] According to some embodiments, the network device includes (i) a network interface component configured to acquire network packets from a router device in real time; (ii) a data processing unit configured to extract packet metadata from network packets; and (iii) a policy component configured to provide policy rules to the router device, wherein the policy rules are generated based on an analysis of the packet metadata.

[0010] According to some embodiments, a method for applying a policy in a router device including memory and a control circuit includes (i) applying one or more policy rules in the router device, and (ii) while applying one or more policy rules, (a) receiving further policy rules from a policy server via a policy agent, and (b) implementing further policy rules via a policy agent by adjusting the data plane in the router device.

[0011] According to some embodiments, the anomaly detection method includes (i) acquiring input network data for a network device, such that the networking data includes operational information and packet metadata for the network device; (ii) classifying the input network data using one or more machine learning models, such that the classification includes identifying anomaly network data from the input network data; and (iii) generating policy rules based on the anomaly network data.

[0012] Accordingly, the methods, devices, and systems disclosed herein provide anomaly detection and policy enforcement in network devices. Such methods, devices, and systems may complement or replace conventional methods for anomaly detection and / or policy enforcement.

[0013] The features and advantages described herein are not necessarily exhaustive, and several further features and advantages will be apparent to those skilled in the art, in particular, given the drawings, specification and claims provided herein. Furthermore, it should be noted that the language used herein has been chosen primarily for readability and educational purposes and not necessarily to describe or limit the subject matter described herein.

[0014] To better understand the various embodiments described, the following descriptions of embodiments should be referred to in conjunction with the following drawings. Similar reference figures in the drawings refer to corresponding parts throughout the drawings and specification. [Brief explanation of the drawing]

[0015] [Figure 1A] This figure shows an exemplary service provider network in several embodiments. [Figure 1B] This figure shows examples of border gateway protocol peering according to several embodiments. [Figure 1C] A diagram showing an exemplary network packet according to some embodiments. [Figure 2] A diagram showing an exemplary network architecture according to some embodiments. [Figure 3A] A diagram showing an exemplary data processing unit component according to some embodiments. [Figure 3B] A diagram showing an exemplary data processing unit component according to some embodiments. [Figure 4A] A diagram showing an exemplary network operating system component according to some embodiments. [Figure 4B] A diagram showing an exemplary network operating system component according to some embodiments. [Figure 5] A diagram showing an exemplary plot of network data according to some embodiments. [Figure 6A] A diagram showing an exemplary device communication according to some embodiments. [Figure 6B] A diagram showing an exemplary device communication according to some embodiments. [Figure 6C] A diagram showing an exemplary device communication according to some embodiments. [Figure 7A] A diagram showing an exemplary policy communication according to some embodiments. [Figure 7B] A diagram showing an exemplary policy communication according to some embodiments. [Figure 8A] A flowchart showing a method for anomaly mitigation according to some embodiments. [Figure 8B] A flowchart showing a method for policy application according to some embodiments. [Figure 8C] A flowchart showing a method for anomaly detection according to some embodiments.

Embodiments for Carrying Out the Invention

[0016] Next, embodiments are referred to. These examples are shown in the accompanying drawings. In the following description, numerous specific details are set forth in order to obtain an understanding of the various described embodiments. However, as will be apparent to those skilled in the art, the various described embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0017] Network traffic data can be recorded, but due to the rapidly increasing volume of network data, actively monitoring it is becoming extremely difficult. For example, with a 100 Gbps connection, one valid 64-octet IP packet can be provided every 5 nanoseconds in a single path. Network data can be in the exabyte range, and since activities occur at nearly the speed of light, significant challenges arise for real-time tracking and management.

[0018] In the present disclosure, improved means for network security, routing / switching, network management, and fault analysis are described. The present disclosure also includes descriptions of protocols and network security, dynamic optimization, and autonomous network operation. Advantages may include one or more of the following: improved response time for fault analysis and mitigation (e.g., real-time), autonomous policy generation and application, scaling to next-generation traffic densities (e.g., from 400 / 800 gigabits per second (Gbps) to terabits per second (Tbps) scale), and a distributed architecture that interacts with existing systems without requiring replacement of existing system components.

[0019] Figure 1A shows an exemplary service provider network according to several embodiments. As shown in Figure 1A, an access network 102 is coupled to edge providers 104 (e.g., 5G new radio (NR) towers or 4G evolved node B (eNB)). Each edge provider 104 may be communicatively coupled to one or more mobile devices 116, residences 118, and / or business locations 120. The access network 102 includes a plurality of access control routers 106 and a plurality of aggregation routers 108. The aggregation routers 108 communicatively couple the access network 102 to an aggregation network 110 and optionally to one or more edge cloud networks 114. The aggregation network 110 may be a multiprotocol label switching (MPLS) network and / or a backhaul network. The aggregation network 110 is coupled to cloud networks 114-3 and network 112. Network 112 may be an MPLS network and / or a core IP network. Network 112 may be coupled to one or more further networks (e.g., the Internet). In some embodiments, the aggregation network 110 is a 4G / 5G aggregation network.

[0020] Figure 1B shows examples of border gateway protocol peering in several embodiments. Figure 1B shows multiple interconnected networks 140. Each network 140 includes a router 142. Border Gateway Protocol (BGP) allows routing decisions to be made autonomously based on network routes, network policies, and / or rule sets configured by network administrators. For example, BGP routing guides Internet Protocol (IP) packets from end users to their final destinations across the Internet. BGP enables coordination between different networks interconnected on a single global communications infrastructure (e.g., the Internet). BGP provides a standardized way for networks (e.g., autonomous systems) to exchange routing and reachability information. A BGP attack could route traffic to a malicious server and / or cause routing delays / failures.

[0021] Figure 1C shows network packets 150 in several embodiments. Network packets 150 include Media Access Control (MAC) level 152 (e.g., including a physical address), IP level 154 (e.g., including a logical IP address), TCP / UDP level 156 (e.g., including a port number), and HTTP, FTP, DHCP, and / or DNS level 158 (e.g., including data to be sent). Various levels of network packets 150 are used to route network packets 150 from the end user to the final destination.

[0022] Figure 2 shows network systems 200 according to several embodiments. Network systems 200 include network devices 202 (e.g., router devices), a near-end network server 206, and a far-end data center 222. Network systems 200 also include a policy server 220 (e.g., a centralized policy server). In some embodiments, network systems 200 are configured for system monitoring (e.g., anomaly detection, root cause identification, and / or predictive maintenance), managed services (e.g., trouble ticket classification, churn prediction, and / or SLA assurance), and / or intelligent networking (e.g., self-healing networks, dynamic optimization, and / or network design automation). In some embodiments, network systems 200 are cellular, internet, and / or optical networks. In some embodiments, network device 202 includes a policy agent 204. Network device 202 is communicatively coupled to the near-end network server 206 (e.g., via a 10, 25, 40, 100, or 400G connection) and the policy server 220-1. In some embodiments, the network device 202 includes worker nodes. In some embodiments, the worker nodes of the network device 202 host policy agents 204. In some embodiments, the policy agents 204 are used to communicate with a policy server and to apply policies in the data plane of the network device 202.

[0023] The near-end network server 206 includes a network interface 210 (e.g., a smart network interface card (NIC)), one or more processors 216 (e.g., one or more CPUs), one or more data processors 212 (e.g., one or more DPUs), optionally one or more parallel processors 211 (e.g., one or more GPUs), a policy agent 208, and optionally a policy server 213. In some embodiments, the policy agent 208 is used for network server management purposes, for example, to configure and deploy data and AI / ML pipelines according to user configurations from a dashboard. In some embodiments, the components of the near-end network server 206 are communicatively coupled to each other via a communication bus 214 (e.g., a PCI-Express bus). The near-end network server 206 is communicatively coupled to a network device 202, a policy server 220-1, a policy server 220-2, and a far-end data center 222. In some embodiments, one or more parallel processors 211 are configured to perform network analysis and / or machine learning (for example, representing instances of operational devices 404). In some embodiments, the near-end network server 206 communicates with the far-end data center 222 via a remote DMA connection. In some embodiments, the policy server 213 includes only a subset of the functionality of the policy server 220. In some embodiments, the policy server 213 communicates with other policy servers (for example, the policy server 220) and maintains policy rules for router devices that communicate directly with the policy server 213.

[0024] The far-end data center 222 is communicatively coupled to the near-end network server 206 (for example, via a 20 / 30km RDMA over-converged Ethernet (RCoE)v2 connection) and the policy server 220-2. The far-end data center 222 includes the far-end network server 224 and one or more databases 236 (for example, flash storage). The far-end network server 224 includes a network interface 228 (for example, a smart network interface card (NIC)), one or more processors 226 (for example, one or more CPUs), one or more parallel processors 234 (for example, one or more GPUs), and a policy agent 232. In some embodiments, the components of the far-end network server 224 are communicatively coupled to each other via a communication bus 230 (for example, a PCI-Express bus).

[0025] In some embodiments, the network interface 210 performs preprocessing of network data from the network device 202. In some embodiments, the network interface 210 provides the network data (or preprocessed network data) to the data processor(s) 212 via the bus 214. In some embodiments, the data processor(s) 212 (e.g., a data processing unit) performs a detailed analysis of the network data and generates machine learning (ML) dataset(s) for use by an ML inference model. In some embodiments, the ML dataset(s) are stored in a database at the near-end network server 206 (e.g., a database associated with the data processor(s) 212). In some embodiments, the parallel processor(s) 212 runs an ML inference model that takes the ML dataset(s) as input and performs calculations to generate policies for anomaly detection. In some embodiments, the generated policies are shared with the policy server 213 for storage, distribution, and / or application. In some embodiments, the data processor(s) 212 transmits raw packet data and ML datasets to the database 236 for storage and, optionally, for future ML training (e.g., at a far-end data center 222). In some embodiments, the data processor(s) 212 transmits only the ML datasets to the network interface 228 (e.g., to update the host database in the network server(s) 224). In some embodiments, the network server(s) 224 handles scheduling for each parallel processor(s) 234 and is configured to perform ML model training based on the ML datasets in the host database.

[0026] In some embodiments, network packet data (and device operation data) is transmitted from the network device 202 to the near-end network server 206 via the network interface 210. The network packet data is routed (transferred) to a data processor(s) 212 via the communication bus 214. In embodiments where the near-end network server 206 includes a parallel processor(s) 211, the processed network data (e.g., ML dataset) is routed to the parallel processor(s) 211 via the communication bus 214 for analysis and machine learning. The data processor(s) 212 transmits the network packet data (and / or data derived from the network packet data) to the network interface 228 and / or database(s) 236. The network interface 228 provides the data to the parallel processor(s) 234 via the communication bus 230. The parallel processor(s) 234 may retrieve network data (e.g., historical network data) from the database(s) 236 and / or store analysis results and processed data in the database(s) 236.

[0027] In some embodiments, policy messages are transmitted between policy servers 220 and 213 and policy agents 204, 208, and 232. For example, a policy request is sent from a policy agent to a policy server, and a policy response is sent from the policy server in response (for example, as described below with respect to Figures 6A to 6C). In some embodiments, policy agent 204 communicates with policy server 213 via network interface 210. In some embodiments, policy servers communicate with each other (for example, to status / relay policy information). In some embodiments, policy agents are configured to implement policy rules in the control plane. In some embodiments, policy agents are configured to implement policy rules by configuring tertiary associative memory (TCAM) in network devices. In some embodiments, policy agents are configured to remove deprecated rules (for example, in response to instructions from a policy server). In some embodiments, policy servers are configured to localize policy rules (for example, not propagating policy rules to devices to which the rules do not apply).

[0028] Figures 3A and 3B illustrate exemplary data processing unit components according to several embodiments. Figure 3A shows a data processing unit (e.g., an instance of a DPU 212) including component 302 (e.g., a software component), memory 328 (e.g., DRAM), switch 324 (e.g., a PCIe switch), and component 326 (e.g., a hardware component). Component 302 includes a management plane 304, a control plane 310, a data plane 314, a telemetry module 306, a security module 308, and a storage module 312. Component 326 includes a network module 342, a processor 336, a cache 330, a microengine 332, and a switch 334 (e.g., a PCIe switch). Switch 334 is coupled to storage 338 and / or a parallel processor (e.g., a GPU). In some embodiments, storage 338 is separate from the data processing unit (e.g., the data processing unit is coupled to remote storage). The network module 342 is coupled to one or more networks 340. The network module 342 includes one or more data path accelerators 344, an RDMA / TCP / UDP component 346, a pack-switching / processing accelerator 348, and an Ethernet Mac / Phys component 349. In some embodiments, the data processing unit 300 includes a programmable data path accelerator. In some embodiments, the data processing unit 300 has a bandwidth in the range of 200 Gb / s to 800 Gb / s. In some embodiments, the data processing unit 300 includes multiple DDR channels. In some embodiments, the data processing unit 300 includes an embedded application-specific integrated circuit (ASIC). In some embodiments, the microengine 332 is implemented on the data plane. Component 326 is coupled to multiple server hosts 322 via a switch 324.

[0029] Figure 3B shows a data processing unit 350 communicatively coupled to a parallel processing unit 360 (e.g., a GPU). The data processing unit (DPU) 350 includes a management plane 304, a security module 308, a storage module 312, a data plane 314 (e.g., for real-time telemetry), and a telemetry module 306. The DPU 350 also includes a local policy server 352 and multiple tenancies 354. In some embodiments, each tenancy 354 is a separate virtual machine and / or a separate security group. In some embodiments, the DPU 350 is configured for traffic analysis, route optimization, and / or microsegmented security. The parallel processing unit 360 includes a global policy server 362 (for example, configured to generate policy rules based on inference), an inference module 364 (for example, configured to provide inference based on network data analysis), a modeler 364 (for example, configured to train and / or evaluate machine learning models), a dataset processing module 366 (for example, an ETL module), a machine learning module 370, and a data plane 368. In some embodiments, the ETL module is separate from the dataset processing module 355 (for example, the ETL module generates ML datasets, and the dataset processing module reads the datasets to be processed by the ML module). In some embodiments, the parallel processing unit 360 is configured for automated real-time policy control and response.

[0030] Figures 4A and 4B illustrate exemplary network operating system components according to several embodiments. As shown in Figure 4A, a network device 428 (e.g., an instance of network device 202) is communicatively coupled to a policy server 414 (e.g., an instance of policy server 220). The policy server 414 is communicatively coupled to an operational device 404 (e.g., an instance of far-end network server 224). The operational device 404 is coupled to a collector 402 (e.g., an instance of near-end network server 206). In some embodiments, the collector 402 is a standalone device (e.g., a dedicated switch device). In some embodiments, the collector 402 is a dedicated peering switch router. In some embodiments, the collector 402 is configured to listen for data plane and control protocol messages (e.g., of network device 428). In some embodiments, the collector 402 is configured for extraction, transformation, and loading functions for data plane traffic. In some embodiments, the collector 402 is configured for 25 Gigabit, 100 Gigabit, and / or 400 Gigabit Ethernet. In some embodiments, the collector 402 is configured to collect data at the system's transmission rate (for example, when data is transmitted over the network). In some embodiments, the collector 402 is configured to mirror packet metadata of packets received at the network device 428. In some embodiments, the collector 402 preprocesses network packets (for example, by removing metadata and / or certain types of packets). In some embodiments, the collector 402 is a component of a router or switch device (for example, the network device 428). In some embodiments, the collector 402 is a data processing unit or includes a data processing unit. In some embodiments, the collector 402 is configured to mirror network traffic.

[0031] The network device 428 includes an operating system 430 (e.g., the Linux® operating system), infrastructure 440, hardware-specific layer (HSL) 436, communication module 442, worker node 432, and management plane 444. The communication module 442 may include VLAN, xSTP, PTP, SyncE, and / or LACP modules. The communication module 442 may include OSPF, ISIS, BGP, and / or VRRP modules. The communication module 442 may include PIM-SM / DM, PIM, Bidir, IGMP, and / or MLD modules. The communication module 442 may include segment routing (e.g., SR / MPLS and / or SRv6) modules. The communication module 442 may include IP / MPLS (LDP / RSVP-TE) and L2 / L3 VPN modules. The communication module 442 may include an EVPN-based service module. The communication module 442 may include a system management module. The communication module 442 may include a carrier Ethernet module (e.g., CFM, EFM, Y1731, and / or 8031). The management plane 444 may be communicatively coupled to one or more other network elements (e.g., collector 402) 446 (e.g., via NetConf, REST, GNMI, SNMP, and / or C-API channels). The worker node 432 includes a policy agent 434 (e.g., an instance of policy agent 204). In some embodiments, the infrastructure 440 includes an NSM, RIBS, and / or MRIB infrastructure. In some embodiments, the HSL 436 is communicatively coupled to the infrastructure 440 via a software subsystem (e.g., a hardware abstraction layer (HAL)). In some embodiments, the network device 428 is a switch and / or router device (e.g., an instance of aggregation router 108). In some embodiments, the network device 428 is a white-box device.

[0032] In some embodiments, worker node 432 is a containerized module running on network device 428. In some embodiments, worker node 432 is a cross-platform container. In some embodiments, the policy agent 434 of worker node 432 subscribes to policy messages from a policy server (e.g., policy server 414). In some embodiments, worker node 432 implements endpoint policies (e.g., via access control lists (ACLs), traffic rules, and / or routing changes). In some embodiments, worker node 432 is part of an ETL pipeline to operational device 404. In some embodiments, worker node 432 is implemented as a Docker container (e.g., a Linux® container). In some embodiments, worker node 432 operates as a node in a Kubernetes cluster. In some embodiments, the policy agent 434 of worker node 432 is configured to subscribe to policy messages, apply received policies to the data plane of network device 428, and / or establish an ETL pipeline to an external data processing unit (e.g., data processing unit 300). In some embodiments, the worker node 432 is a control and policy service module. In some embodiments, the policy agent 434 is configured to communicate with the control plane of a network device.

[0033] In some embodiments, infrastructure 440, HSL 436, and worker node 432 are components of the data plane (e.g., data plane 314) of network device 428. In some embodiments, the data plane is modular, scalable, and / or interchangeable. In some embodiments, the data plane is implemented on a system-on-chip or network-specific application integrated circuit (ASIC) component. In some embodiments, the data plane provides protocol and hardware services. In some embodiments, communication module 442 is a component of the control plane (e.g., control plane 310). In some embodiments, the control plane is modular, scalable, and / or fault-tolerant. In some embodiments, the control plane provides open standards-based support (e.g., ITU, IEEE, OIF, IETF, OCP, TIP, and / or MEF). In some embodiments, the control plane provides container support for third-party applications. In some embodiments, the control plane provides protocol support (e.g., L2, L3, routing, switching, MPLS, and / or data center and carrier Ethernet networking). In some embodiments, the control plane is configured to make routing decisions. In some embodiments, the management plane 444 is transaction-oriented. In some embodiments, the management plane 444 has a model-driven architecture.

[0034] The policy server 414 includes a message server 424 (for communicating with policy agents), a topic registry 422, an event publisher 420, an event generator 418, and a policy graph database server 416. The policy graph database server 416 communicates with one or more graph policy clients (e.g., policy graph client 412). In some embodiments, the policy graph database server 416 propagates policy-based access control rules to the event generator 418. In some embodiments, the policy server 414 includes a graph-oriented database (e.g., policy graph database server 416) for storing policy rules. In some embodiments, the policy server 414 implements a publish-subscribe type message-oriented server (e.g., message server 424). In some embodiments, the policy server 414 translates policy rules into policy messages (e.g., actionable insights). In some embodiments, the policy server 414 sends policy updates via policy messages (e.g., using a policy protocol). In some embodiments, the policy server 414 provides a mechanism for translating policies into flow specification rules (e.g., rules shareable via BGP) based on information received from the operating device 404. In some embodiments, the policy server 414 is configured to autonomously block and / or reroute abnormal traffic by issuing corresponding policy rules. In some embodiments, the policy server 414 is statically configured by the network administrator. In some embodiments, the policy server 414 is configured to extend existing policy rules (rather than overwriting existing rules). In some embodiments, the policy rules include one or more traffic policy rules, one or more security policy rules, and / or one or more routing policy rules (e.g., QoS traffic optimization).

[0035] The operational device 404 includes an extract, transform, and load (ETL) module 406, a model training / evaluation module 408, a scoring module 410, and a graph policy client 412. In some embodiments, the operational device 404 ingests protocol metadata and applies pattern matching capabilities. In some embodiments, the metadata is time-series data. In some embodiments, the operational device 404 generates machine models for machine learning operations. In some embodiments, the operational device 404 generates machine models based on training data and / or existing policy rules. In some embodiments, the operational device 404 provides inference via network policy rules. In some embodiments, the operational device 404 is implemented in a cellular data center. In some embodiments, the ETL module 406 performs ETL operations on packet headers from the collector 402. In some embodiments, the operational device 404 is configured to provide real-time detection of network anomalies and / or malicious attacks. In some embodiments, the operational device 404 and the policy server 414 are located in the same location (e.g., in the same data center). In some embodiments, the operational device 404 is configured to analyze raw packet metadata over a pre-configured rolling window. In some embodiments, the operational device 404 is configured to validate predictions to identify suspicious packets, traffic patterns, and / or relationships. In some embodiments, the operational device 404 is configured to notify of unacceptable behavior and / or dynamically adapt network policies (for example, in cooperation with a policy server 414). In some embodiments, the operational device 404 is configured to predict expected behavior based on empirical monitoring and / or acquired knowledge. In some embodiments, the operational device 404 is a component of a router or switch device.In some embodiments, the model training / evaluation module 408 includes a model for traffic classification, a model for traffic routing, and / or a model for network maintenance. In some embodiments, the model training / evaluation module 408 performs classification and / or regression-based analysis.

[0036] Figure 4B shows exemplary components of a network device (e.g., network device 428) according to several embodiments. The network device in Figure 4B includes a HAL 438, a network services module 454, and a platform abstraction layer (PAL) 450. The network device in Figure 4B further includes several protocol modules (e.g., IPv4, IPv6, multicast, MPLS, and layer 2 modules). In some embodiments, the IPv4 modules include RIPvVv2, OSPF-v2, BGP-4, IS-IS4, CSPF-OSPF, and / or CSPF-ISIS4 modules. In some embodiments, the IPv4 modules include RIPng, OSPF-v3, BGP-4+, and / or IS-IS5 modules. In some embodiments, the multicast modules include PM-SM, PM-SM v6, PM-DM, PM-DM v6, IGVP vVv2, and / or DVMPP modules. In some embodiments, the MPLS module includes LDP, RSVP-TE, DiffServ / DiffServ-TE, L2 VC, VPLS, and L3VPN modules. In some embodiments, the Layer 2 module includes VLAN (832 1pQ 832GVRP), multicast (GMRP GMP snooping), spanning tree (STP RSTP, MSTP), and / or PORT authentication (802) modules. In some embodiments, the protocol module includes a hybrid switch-router module.

[0037] Figure 5 shows exemplary plots of network data according to several embodiments. For example, network data 500 is plotted and an outlier 504 is identified. In some embodiments, the network data includes routing data. Analysis of the network data may be performed in the model training / evaluation module 408 and / or the scoring module 410. In some embodiments, the operating device 404 classifies the network data as either normal or abnormal. In some embodiments, the operating device 404 detects BGP routing security breaches and other anomalies based on the classified network data. In some embodiments, the model training / evaluation module 408 includes one or more supervised machine learning models and one or more unsupervised machine learning models. In some embodiments, the supervised machine learning model(s) include one or more of the following: logistic regression models, random forest models, k-nearest neighbors (KNN) models, and support vector machine (SVM) models. In some embodiments, the SVM model is a two-class classifier, outputting 1 to indicate anomalies and -1 (or 0) to indicate non-anomalies. In some embodiments, the scoring module 410 performs real-time classification (e.g., binary classification) of the network data. In some embodiments, a classification hyperplane is trained using labeled training samples (e.g., in model training / evaluation module 408). In some embodiments, a radial basis function (e.g., a kernel function) is used to transform the data into a linearly separable form. In some embodiments, a grid search is used to select hyperparameters.

[0038] Figures 6A to 6C illustrate exemplary device communication in several embodiments. Figure 6A shows an exemplary policy exchange protocol between a client 602 (e.g., a policy agent 204) and a server 604 (e.g., an instance of policy server 220 or 213). Figure 6B shows a finite state machine (FSM) version of the policy exchange protocol shown in Figure 6A. In the example in Figure 6A, the client 602 and server 604 are initially idle, and server 604 is waiting for incoming communication. First, client 602 initiates a handshake (606), which server 604 accepts, and a connection is established (608). After the connection is established, a policy session is established (610), and policy session services are performed (612). Once the policy session services are complete, the session ends (614), and the connection is terminated optionally. In some embodiments, the connection is terminated in response to a user termination request. In some embodiments, the connection is terminated in response to a session establishment failure (e.g., the client cannot agree with the server). In some embodiments, establishing a policy session involves exchanging functions. In some embodiments, establishing a policy session involves client 602 subscribing to the functions of server 604. In some embodiments, the policy session is maintained via keep-alive messages. In some embodiments, after the policy session is established, application-specific messages are exchanged between client 602 and server 604. In some embodiments, the policy server is a policy translation gateway (e.g., one for interacting with an existing network architecture). In some embodiments, the policy translation gateway implements a native protocol (e.g., a policy exchange protocol). In some embodiments, the policy translation gateway implements a standards-based protocol (e.g., IETF, IEEE, and / or ITU-T (e.g., for BGP flow specifications)). In some embodiments, the policy translation gateway implements a proprietary protocol (e.g., via a plug-in architecture).

[0039] Figure 6C shows an exemplary policy exchange protocol with multiple policy session services. First, a connection is established (608), and then a policy session is established (610). Once the policy session is established, a service management message (620) is sent to the server and acknowledged (622). A security policy synchronization request (612-1) is sent from client 602, and a security policy synchronization response (612-2) is sent from server 604. In the example in Figure 6C, a security policy add message (612-3) and a security policy delete message (612-4) are sent from server 604. After the policy session service has been performed, a service management message (624) is sent from client 602 and acknowledged by server 604 (626). In some embodiments, server 604 responds to the open message (service management message) with an acknowledgment message if the policy session is successful, and with an error message if the policy session fails.

[0040] Figures 7A and 7B illustrate exemplary policy communications according to several embodiments. Figure 7A shows an exemplary message including an Ethernet header 702, an IPv4 header 704, a TCP header 706, and a TCP payload 708. The TCP payload 708 includes a plurality of messages 712-1 to 712-n. Message 712-1 includes a message type 716 (e.g., 2 bytes), a message length 718 (e.g., 2 bytes), and a message value 720. The message value 720 includes a plurality of submessages 722-1 to 722-m. Submessage 722-1 includes a submessage type 726 (e.g., 2 bytes), a submessage length 728 (e.g., 2 bytes), and a submessage value 730. In some embodiments, the policy message uses a non-TCP protocol (e.g., UDP). In some embodiments, the policy message uses protocol buffer encoding. In some embodiments, the policy message uses time-length value (TLV) encoding. In some embodiments, each message is encoded in TLV format. In some embodiments, each message includes one or more submessages encoded in TLV format.

[0041] Figure 7B shows exemplary policy messages according to several embodiments. A synchronization request message 640 includes a message type 752-1, a message length 754-1, a synchronization request flag 758, and reserved bits 760-1. A synchronization response 642 includes a message type 752-2, a message length 754-2, a table version 762-1, a synchronization response flag 764, reserved bits 760-2, and policy objects 1 to n. A policy add message 644 includes a message type 752-3, a message length 754-3, a table version 762-2, an add flag 766, reserved bits 760-3, and policy objects 1 to m. A policy delete message 646 includes a message type 752-4, a message length 754-4, a table version 762-3, a delete flag 768, reserved bits 760-4, and policy identifiers 1 to p. A policy delete message 648 includes a message type 752-5, a message length 754-5, a table version 762-4, a delete flag 770, and reserved bits 760-5. In some embodiments, the table version 762, the flag, and the reserved bits form a common header (e.g., a 4-byte header). In some embodiments, the policy object includes a policy identifier (e.g., 2 bytes), a match component, and an action component. In some embodiments, the match component includes match criteria (e.g., source and destination address prefixes, IP protocol, and transport protocol port number). In some embodiments, the action component has an action type (e.g., shape, rate limit, redirect, deny, allow, and drop).

[0042] In some embodiments, the matching component includes a prefix component, a protocol type component (e.g., All, TCP, UDP, or ICMP), a port number component, a port range component, a fragment component (e.g., DF or FF), a DSCP component, a TCP flag component, and / or a packet length component. In some embodiments, the matching component includes one or more operators (e.g., numeric operators and / or bitmask operators). Exemplary numeric operators include logical AND, logical OR, equal to, less than, and greater than operators. An example bitmask operator is the NOT operator.

[0043] In some embodiments, a particular packet is considered to match a flow if it matches the logical AND of all components present in the representation. In some embodiments, components must follow a strict type order in ascending numerical order. For example, a given component type may exist within a flow specification (e.g., exactly 1). If present, it must precede any component with a higher numerical type value. In some embodiments, all combinations of components within a single flow specification are permitted. However, some combinations should not be propagated because they may not match any packet (e.g., "ICMP type AND port" does not match any packet).

[0044] In some embodiments, message types include control messages (e.g., open, keep-alive, notification, and service management messages) and service-specific messages (e.g., security / policy messages). In some embodiments, control messages are used to establish / maintain policy / service sessions. For example, a keep-alive message is a heartbeat mechanism used to check whether a remote peer is still active. As another example, notification messages may be used to notify a peer of an error or reset condition. In some embodiments, service management messages allow a policy client to set up a service session between the client and the server. In some embodiments, service management messages include subscribe, unsubscribe, and acknowledgment messages. In some embodiments, service-specific messages include synchronization requests, synchronization responses, policy add messages, and / or policy delete messages.

[0045] Figure 8A is a flowchart illustrating the anomaly mitigation method 800 according to several embodiments. In some embodiments, the method 800 is performed in a network device (e.g., network device 202 or near-end network server 206). In some embodiments, the method 800 is performed in a network system (e.g., network system 200). In some embodiments, the method 800 is performed in one or more of the following: a network device (e.g., network device 202), a near-end network server (e.g., near-end network server 206), and a far-end data center (e.g., far-end data center 222). For clarity, the method 800 is described below as being performed by a network system.

[0046] The network system obtains metadata for multiple network packets (802). For example, the network system obtains metadata using collector 402 and / or ETL module 406. In some embodiments, the metadata includes packet header information. In some embodiments, multiple network packets include one or more control protocol packets. In some embodiments, network packets correspond to optical networks, microwave-based networks, cellular networks, and / or internet networks.

[0047] The network system acquires operational information corresponding to one or more network devices (804). For example, the network system acquires operational information for network devices 202 and / or 428. In some embodiments, metadata and / or operational information are acquired via a network collector device. In some embodiments, the operational information includes one or more of the following: information about the operational status of one or more network devices, information about the network status detected by one or more network devices, and information about the hardware and / or software of one or more network devices. In some embodiments, the operational information includes telemetry data for the network devices (for example, acquired via a telemetry module 306). In some embodiments, the operational information includes information about the power supply of the network devices, the transmit power of the network devices, the temperature of the network devices, the transmit quality of the network devices, and / or operating system information from the network devices.

[0048] In some embodiments, the network system generates time-series profiles of network elements and network operations (806), and anomalies are detected using these time-series profiles. For example, the time-series profiles are generated using a model training / evaluation module 408. In some embodiments, anomalies are detected using a scoring module 410.

[0049] The network system detects anomalies in multiple network packets by analyzing acquired metadata (808). For example, anomalies are identified using the model training / evaluation module 408 and / or the scoring module 410. In some embodiments, anomalies are detected using pattern matching. In some embodiments, anomalies are detected using one or more machine learning models. In some embodiments, anomalies are detected via an operating device (e.g., operating device 404). In some embodiments, anomalies correspond to a faulty network component. In some embodiments, anomalies correspond to malicious activity. In some embodiments, anomalies are routing anomalies.

[0050] The network system generates policy rules without human intervention based on detected anomalies (810). For example, policy rules are generated using an operational device 404 and communicated to a policy server (for example, sent via a graph policy client 412). In some embodiments, policy rules include an evaluation component and an action component. In some embodiments, generating policy rules includes extending an existing set of policy rules. For example, the network system identifies an anomaly, identifies the cause of the anomaly, and generates a new policy rule for the cause. For example, the new policy rule drops or reroutes data from the cause.

[0051] The network system applies policy rules on one or more network devices (812). For example, a policy rule is sent to a policy agent 434, which then applies the policy rule on network device 428. In some embodiments, applying a policy rule includes isolating and / or blocking matching packets. In some embodiments, the policy rule is applied via a policy agent implemented on each of the one or more network devices.

[0052] Figure 8B is a flowchart illustrating method 820 of policy enforcement according to several embodiments. In some embodiments, method 820 is performed on a network device (e.g., network device 202). In some embodiments, method 820 is performed on a network system (e.g., network system 200). For clarity, method 820 is described below as being performed by a network device.

[0053] A network device applies one or more policy rules in a router device (822). For example, a network device applies one or more policy rules via policy agents 204 and / or 434. In some embodiments, one or more policy rules are applied in a near-end network server 206 via policy agent 208. In some embodiments, policy agent 208 is configured to communicate with one or more remote policy servers (e.g., policy server 220) via a policy protocol. In some embodiments, the policy agent is implemented as a worker node. In some embodiments, the policy agent is implemented within the control plane of the router device. In some embodiments, the policy agent is implemented as a Docker container. In some embodiments, one or more policy rules include one or more of traffic rules, routing changes, and access control lists. In some embodiments, the router device is an aggregation router.

[0054] While applying one or more policy rules (824), the network device receives additional policy rules from the policy server via the policy agent (826). For example, additional policy rules are received from policy servers 220-1 and / or 220-2.

[0055] While applying one or more policy rules (824), the network device implements further policy rules by tuning the data plane in the router device (e.g., data plane 314) via a policy agent (828). In some embodiments, tuning the data plane includes writing the further policy rules to the content-addressable memory of the router device.

[0056] In some embodiments, a network device subscribes to policy messages from a policy server via a policy agent (830), and one or more policy rules are received via the policy messages. For example, policy agent 204 subscribes to policy server 220-1.

[0057] Figure 8C is a flowchart showing an anomaly detection method 840 according to several embodiments. In some embodiments, method 840 is performed on a network device (e.g., a near-end network server 206). In some embodiments, method 840 is performed on a network system (e.g., a network system 200). For clarity, method 840 is described below as being performed by a network system.

[0058] The network system obtains input network data from network devices (842). The networking data includes operational information for the network devices (e.g., operational plane information and control plane information) and packet metadata. For example, the network device is network device 202. As another example, the network device is network device 428 or collector 402. In some embodiments, the input network data corresponds to changes in the Border Gateway Protocol (BGP). In some embodiments, the input network data includes protocol metadata for one or more network packets. In some embodiments, the operational information includes one or more of the following: information about the operational state of the network device, information about the network state detected by the network device, and information about the hardware and / or software of the network device.

[0059] The network system classifies input network data using one or more machine learning models (844) (for example, via the model training / evaluation module 408), which includes identifying anomalous network data from the input network data. In some embodiments, the classification is binary classification (e.g., normal or anomalous). In some embodiments, one or more machine learning models include support vector machine (SVM) models. In some embodiments, one or more machine learning models include logistic regression models, random forest models, or k-nearest neighbors (KNN) models. In some embodiments, one or more machine learning models include unsupervised deep learning models. In some embodiments, one or more machine learning models include SVM models and unsupervised models. In some embodiments, the SVM models are trained on pre-labeled data, and the unsupervised models are configured to learn autonomously. In some embodiments, the unsupervised models are configured to learn through a set of rewards and penalties. In some embodiments, one or more machine learning models include models for network traffic analysis, models for network security analysis, and / or models for network maintenance analysis. In some embodiments, the input network data is classified in real time. In some embodiments, classifying the input network data includes performing binary classification. In some embodiments, classifying the input network data involves performing a radial basis function to linearly separate the input network data.

[0060] The network system generates policy rules based on abnormal network data (846). For example, policies are generated on an operating device (e.g., operating device 404) and shared with the policy server 414 via the graph policy client 412 and the policy graph DB server 416.

[0061] In some embodiments, the network system obtains a classification hyperplane for a supervised machine learning model by training the supervised machine learning model using labeled training data (848).

[0062] Next, some exemplary embodiments of the aforementioned methods, devices, systems, and computer-readable storage media will be described.

[0063] (A1) In one embodiment, several embodiments include a method for anomaly mitigation (e.g., method 800). In some embodiments, the method is performed in a network device (e.g., network device 202) having memory and one or more processors. In some embodiments, the method is performed in a network system (e.g., network system 200) having memory and one or more processors. The method includes (i) obtaining metadata for a plurality of network packets; (ii) obtaining operational information corresponding to one or more network devices; (iii) detecting anomalies in the plurality of network packets by analyzing the obtained metadata; (iv) generating policy rules without human intervention based on the detected anomalies; and (v) applying the policy rules on one or more network devices. In some embodiments, anomaly detection is used to predict points of failure and proactively reroute traffic.

[0064] (A2) In some embodiments of A1, policy rules are applied via worker nodes implemented in each of one or more network devices. In some embodiments, each of the one or more network devices includes its own policy agent (policy control module). In some embodiments, each network device has a policy agent within a worker node that communicates with a policy server. In some embodiments, the policy agent includes a Docker container implemented in the control plane. In some embodiments, each worker node is a node in a Kubernetes cluster. In some embodiments, each policy agent subscribes to policy messages from a policy server that generates and / or propagates policy rules. In some embodiments, the policy agent is configured to implement endpoint policies (e.g., traffic rules, routing changes, and access control lists). In some embodiments, policy rules are applied via policy agents implemented in network devices. In some embodiments, the network devices are routers and / or switch devices. For example, the network device is an aggregation router in a service provider network.

[0065] (A3) In some embodiments of A1 or A2, the metadata includes packet header information. In some embodiments, the packet header information includes a version number, length, service type, packet identifier, source IP address, destination IP address, and / or checksum data.

[0066] (A4) In some embodiments of A1 to A3, multiple network packets include one or more control protocol packets, for example, Transmission Control Protocol (TCP) packets.

[0067] (A5) In some embodiments of A1 to A4, the method further includes generating time-series profiles of network elements and network operations, and anomalies are detected using the time-series profiles. For example, the time-series profiles combine different time-series types to assign locations.

[0068] (A6) In some embodiments of A1 to A5, anomalies are detected using pattern matching. For example, anomalies are detected by testing network packets to determine whether they have certain characteristics.

[0069] (A7) In some embodiments of A1 to A6, anomalies are detected using one or more machine learning models (e.g., models held in the operating device 404). In some embodiments, the machine learning models include one or more of the following: logistic regression models, random forest models, decision tree models, k-nearest neighbors (KNN) models, and support vector machine (SVM) models. In some embodiments, one or more machine learning models include a two-class classifier (e.g., outputting a value of 1 to indicate a configured anomaly and a value of 0 to indicate standard / normal data).

[0070] (A8) In some embodiments of A1 to A7, metadata is acquired via a network collector device (e.g., collector 402). In some embodiments, the network collector device is configured to collect data at the network transmission rate. In some embodiments, the network collector device is configured to passively monitor / extract packet metadata. In some embodiments, the router mirrors the received network data and sends the mirrored data to a nearby server for anomaly analysis.

[0071] (A9) In some embodiments of A1 to A8, anomalies are detected via an operating device (e.g., operating device 404). In some embodiments, anomaly detection is performed in a cellular data center. In some embodiments, anomaly detection is performed in a far-end server. In some embodiments, anomaly detection is performed in a near-end server (e.g., a server located in the same location as the router that provides the packet data).

[0072] (A10) In some embodiments of A1 to A9, policy rules are generated via an operating device (e.g., operating device 404). In some embodiments, policy rules are published by a policy server that receives policy rules from the operating device. In some embodiments, the policy server includes a policy graph database, an event generator, an event publisher, a topic registry, and a messenger component. In some embodiments, the policy server is a far-end server. In some embodiments, the policy server is a component of a far-end network server (e.g., far-end network server 224) and / or a public cloud. In some embodiments, the policy server is a near-end server (e.g., a server located in the same location as the router that provides packet data). In some embodiments, the policy server is a component of a near-end server (e.g., near-end network server 206).

[0073] (A11) In some embodiments of A1 to A10, the anomaly corresponds to malicious activity (e.g., a DDoS attack).

[0074] (A12) In some embodiments of A1 to A11, an anomaly includes a routing anomaly. For example, an anomaly corresponds to a change in Border Gateway Protocol (BGP) routing.

[0075] (A13) In some embodiments of A1 to A10, the anomaly corresponds to a faulty network component, for example, the network component having a memory or switching error.

[0076] (A14) In some embodiments of A1 to A13, the network packet corresponds to an optical network, a microwave-based network, a cellular network, and / or an internet network.

[0077] (A15) In some embodiments of A1 to A14, the policy rule includes an evaluation component and an action component (as previously described with respect to Figures 7A to 7B, for example).

[0078] (A16) In some embodiments of A1 to A15, generating policy rules involves extending an existing set of policy rules. For example, the generated policy rules are updates to existing policy rules. In another example, the generated policy rules complement an existing set of policy rules.

[0079] (A17) In some embodiments of A1 to A16, the operational information includes one or more of the following: information about the operational status of one or more network devices, information about the network status detected by one or more network devices, and information about the hardware and / or software of one or more network devices. In some embodiments, the operational information includes information about the power supply, the strength of the communication channel, the operating temperature, and / or the signal strength.

[0080] (B1) In other embodiments, some embodiments include a network device (e.g., a network device 428 or a data processing unit 300). The network device includes (i) a network interface component (e.g., a network interface 210) configured to receive network packets from a router device in real time; (ii) a data processing unit (e.g., a data processor 212) configured to extract packet metadata from network packets; and (iii) a policy component (e.g., a policy server 213) configured to provide policy rules to a router device, wherein the policy rules are generated based on an analysis of the packet metadata. In some embodiments, the network device is configured to perform the methods described herein (e.g., A1-17, C1-C8, and / or D1-D17). In some embodiments, the network device is configured to preprocess network packets (e.g., discard irrelevant packet information). In some embodiments, the network interface component is a PCI-Express switch.

[0081] (B2) In some embodiments of B1, the router device is an aggregation router device (e.g., aggregation router 108). In some embodiments, the router device is a network element within a service provider network. In some embodiments, the router device is a network element deployed within a service provider network as part of access, aggregation, data center, core, or transport.

[0082] (B3) In some embodiments of B1 or B2, the network device (e.g., a network interface component) is further configured to obtain operational information (e.g., telemetry information and / or operational status of the router device) from the router device, and policy rules are further generated based on the analysis of the operational information.

[0083] (B4) In some embodiments of B3, the operational information includes one or more of the following: information about the operating state of the router device, information about the network state detected by the router device, and information about the hardware and / or software of the router device. In some embodiments, the operational information includes information about the power supply, the strength of the communication channel, the operating temperature, and / or the signal strength.

[0084] (B5) In some embodiments of B1 to B4, the network device further includes a machine learning component (e.g., a parallel processor(s) 211) configured to analyze packet metadata and provide inferences based on the analysis.

[0085] (B6) In some embodiments of B5, the network device further includes a policy component (e.g., a policy server 213) configured to generate policy rules based on inference.

[0086] (B6) In some embodiments of B5 or B6, the machine learning component includes a graphics processing unit (or other parallel processor).

[0087] (B7) In some embodiments of B1 to B6, the network device is configured to (i) provide packet metadata to a remote server (e.g., far-end network server 224) and (ii) receive policy rules from the remote server (e.g., via policy server 220) in response to providing packet metadata. In some embodiments, the network device stores ML datasets and / or raw data in storage (e.g., near-end storage), which is used by the remote server, for example, to train an ML data model. In some embodiments, the training results in an inference model that can be loaded into the network device (e.g., near-end network server) as a new inference model to generate new, updated policy rules.

[0088] (B8) In some embodiments of B1 to B7, the network interface component is configured to receive network packets at a variable rate. In some embodiments, the variable rate is in the range of 10 to 800 G. In some embodiments, the variable rate is based on the network bandwidth of the router device.

[0089] (B9) In some embodiments of B1 to B8, the network interface component and the data processing unit are communicatively coupled via a communication bus. For example, the communication bus is a PCI-Express bus.

[0090] (B10) In some embodiments of B1 to B9, the network interface component is a smart network interface card. In some embodiments, the smart network interface card is configured to receive data at a variable speed (for example, corresponding to the network's speed of operation).

[0091] (C1) In other embodiments, some embodiments include a method for applying a policy (e.g., method 820). In some embodiments, the method is performed in a network device having memory and one or more processors (e.g., network device 202). In some embodiments, the method is performed in a network system having memory and one or more processors (e.g., network system 200). The method includes (i) applying one or more policy rules in a router device, and (ii) while applying one or more policy rules, (a) receiving further policy rules from a policy server via a policy agent, and (b) implementing further policy rules via a policy agent by adjusting the data plane in the router device.

[0092] (C2) In some embodiments of C1, the policy agent is implemented within a worker node (for example, a node in a Kubernetes cluster). In some embodiments, the policy agent is a component of the worker node.

[0093] (C3) In some embodiments of C1 or C2, the policy agent is implemented within the control plane of a network device. For example, the network device includes a data plane, a control plane, and a management plane.

[0094] (C4) In some embodiments of C1-C3, the policy agent is implemented as a Docker container. In some embodiments, the policy agent is a component of the Docker container.

[0095] (C5) In some embodiments of C1 to C4, the method further includes subscribing to policy messages from a policy server via a policy agent, where one or more policy rules are received via the policy messages. For example, messages are received from message server 424.

[0096] (C6) In some embodiments of C1 to C5, one or more policy rules include one or more traffic rules, routing changes, and access control lists. In some embodiments, a policy rule includes a set of traffic rules and / or a set of routing rules.

[0097] (C7) In some embodiments of C1 to C6, the network device is an aggregation router. In some embodiments, the network device is a component of an access, aggregation, transport, core, and / or data center network. In some embodiments, the network device is a network element deployed within a service provider network.

[0098] (C8) In some embodiments of C1 to C7, tuning the data plane includes writing additional policy rules to the content-addressable memory of the network device. In some embodiments, tuning the data plane includes tuning the content-addressable memory to filter according to the additional policy rules.

[0099] (D1) In other embodiments, some embodiments include a method for detecting anomalies (e.g., method 840). In some embodiments, the method is performed in a network device (e.g., network device 202) having memory and one or more processors. In some embodiments, the method is performed in a network system (e.g., network system 200) having memory and one or more processors. The method includes (i) acquiring input network data from a network device such that the networking data includes operational information and packet metadata for the network device; (ii) classifying the input network data using one or more machine learning models, including identifying anomalous network data from the input network data; and (iii) generating policy rules based on the anomalous network data. In some embodiments, the network data is analyzed to predict traffic density (and policy rules are generated to load balance the traffic). In some embodiments, the input network data is real-time network traffic and / or operational data of the network device.

[0100] (D2) In some embodiments of D1, one or more machine learning models include a support vector machine (SVM) model.

[0101] (D3) In some embodiments of D1 or D2, one or more machine learning models include a logistic regression model, a random forest model, and / or a k-nearest neighbors (KNN) model.

[0102] (D4) In some embodiments of D1 to D3, one or more machine learning models include unsupervised deep learning models.

[0103] (D5) In some embodiments of D1 to D4, one or more machine learning models include an SVM model and an unsupervised model.

[0104] (D6) In some embodiments of D5, the SVM model is trained on pre-labeled data, and the unsupervised model is configured to learn autonomously. For example, the SVM model is trained in the model training / evaluation module 408.

[0105] (D7) In some embodiments of D5 or D6, the unsupervised model is configured to learn through a set of rewards and penalties. For example, the unsupervised model is or includes an adversarial generative network.

[0106] (D8) In some embodiments of D1 to D7, one or more machine learning models include a model for network traffic analysis, a model for network security analysis, and / or a model for network maintenance analysis. In some embodiments, network packets are analyzed by each model to determine any anomalies.

[0107] (D9) In some embodiments of D1 to D8, the classification of the input network data is performed in real time. For example, the classification includes real-time inference. In some embodiments, the classification includes pattern matching by a supervised machine learning model.

[0108] (D10) In some embodiments of D1 to D9, the input network data corresponds to changes in the Border Gateway Protocol (BGP). For example, the BGP changes are analyzed to determine whether they are valid and / or efficient.

[0109] (D11) In some embodiments of D1 to D10, the input network data includes protocol metadata for one or more network packets. In some embodiments, the input network data includes packet header information for each of the one or more network packets.

[0110] (D12) In some embodiments of D1 to D11, classifying the input network data includes performing a two-class (binary) classification.

[0111] (D13) In some embodiments of D1 to D12, the method further includes obtaining a classification hyperplane for a supervised machine learning model by training the supervised machine learning model using labeled training data.

[0112] (D14) In some embodiments of D1 to D13, the method is performed in a network device. For example, the method is performed in a router and / or switch device.

[0113] (D15) In some embodiments of D1 to D14, classifying the input network data includes performing a radial basis function to linearly separate the input network data.

[0114] (D16) In some embodiments of D1 to D15, the operational information includes one or more of the following: information about the operational status of the network device, information about the network status detected by the network device, and information about the hardware and / or software of the network device. In some embodiments, the operational information includes information about the power supply, the strength of the communication channel, the operating temperature, and / or the signal strength.

[0115] (E1) In other embodiments, some embodiments include a method for applying a policy. In some embodiments, the method is performed in a network device (e.g., network device 202) having memory and one or more processors. In some embodiments, the method is performed in a network system (e.g., network system 200) having memory and one or more processors. The method includes (i) receiving a connection request from a remote device (e.g., client 602), (ii) establishing a communication channel in response to the receipt of the connection request, (iii) establishing a policy session using the established communication channel, and (iv) providing one or more service messages to the remote device through the policy session.

[0116] (E2) In some embodiments of E1, one or more service messages include a synchronization message (e.g., a synchronization response message 642), a policy addition message (e.g., a policy addition message 644), and / or a policy deletion message (e.g., a policy deletion message 646 or a policy delete all message 648).

[0117] (E3) In some embodiments of E1 or E2, the method further includes terminating the policy session after providing one or more service messages (for example, via session termination operation 614). In some embodiments, the session is terminated in response to a user request. In some embodiments, the session is terminated in response to a mismatch between the client and the server.

[0118] (E4) In some embodiments of E1 to E3, one or more service messages include two or more types of service messages.

[0119] (E5) In some embodiments of E4, each type of service message includes one or more bits indicating the message type (e.g., message type 752), one or more bits indicating the message length (e.g., message length 754), and one or more bits specific to the bit type.

[0120] (E6) In some embodiments of E1 to E5, the communication channel is a TCP connection.

[0121] (E7) In some embodiments of E1 to E6, each of one or more service messages includes an Ethernet header, an IP header, and a payload. In some embodiments, each of one or more service messages includes a TCP header. In some embodiments, the payload is a TCP payload. In some embodiments, the payload consists of multiple messages. In some embodiments, each of the multiple messages includes multiple submessages.

[0122] In other embodiments, some embodiments include a computing system comprising one or more processors and memory coupled to one or more processors, the memory storing one or more programs configured to be executed by one or more processors, the one or more programs including instructions for executing any of the methods described herein (for example, methods 800, 820, and 840 and A1-A17, C1-C8, D1-D16, and E1-E7 above).

[0123] In yet another embodiment, some embodiments include a non-temporary computer-readable storage medium that stores one or more programs for execution by one or more processors of a computing system, the one or more programs including instructions for performing any of the methods described herein (for example, methods 800, 820, and 840 and A1-A17, C1-C8, D1-D16, and E1-E7 described above).

[0124] The terminology used in the description of the various embodiments described herein is intended solely to describe specific embodiments and is not intended to limit them. Where used in the description of the various embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural form unless the context clearly indicates otherwise. Furthermore, where used herein, the terms "and / or" will be understood to refer to and encompass all possible combinations of one or more of the enumerated items relating to the description. In addition, where used herein, the terms "includes," "including," "comprises," and / or "comprising" will be understood to indicate the presence of the described features, steps, operations, elements, and / or components, but not to exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0125] As used herein, the term “if” means, depending on the context, “when” or “at the time” or “in response to a decision” or “in response to detection” or “according to the decision that”. Similarly, the phrases “if it is decided” or “if [the described condition or event] is detected” mean, depending on the context, “when it is decided” or “in response to a decision” or “when [the described condition or event] is detected” or “in response to detection of [the described condition or event]” or “according to the decision that [the described condition or event] has been detected.”

[0126] Furthermore, while the terms "first" and "second" are used herein to describe various elements in some cases, it will be understood that these elements should not be limited by these terms. These terms are used solely to distinguish one element from another.

[0127] While some drawings show several logical steps in a specific order, steps that are not order-dependent can be rearranged, and others can be combined or separated. Some rearrangements or other groupings are specifically mentioned, while others are obvious to those skilled in the art; therefore, the rearrangements and groupings presented herein are not an exhaustive list of alternatives. Furthermore, it should be recognized that the steps can be implemented in hardware, firmware, software, or any combination thereof.

[0128] The above description is written with reference to specific embodiments for illustrative purposes. However, the above exemplary description is not intended to be exhaustive or to limit the scope to the exact form disclosed. Many modifications and variations are possible with respect to the above teachings. The embodiments have been selected and described to best illustrate the main principles and practical applications, so that those skilled in the art can best utilize the various embodiments and make various modifications suitable for specific conceivable applications.

Claims

1. It is a network server, A network interface component configured to acquire network packets from a router device in real time, A data processing unit configured to extract packet metadata from the aforementioned network packets, A network server comprising a policy component configured to provide policy rules to the router device, wherein the policy rules are generated based on an analysis of the packet metadata.

2. The network server according to claim 1, wherein the router device is an element of a service provider network.

3. The network server according to claim 1 or 2, wherein the network interface component is further configured to acquire operational information from the router device, and the policy rules are further generated based on an analysis of the operational information.

4. The network server according to claim 3, wherein the operation information includes one or more of the following: information relating to the operating status of the router device, information relating to the network status detected by the router device, and information relating to the hardware and / or software of the router device.

5. The network server according to any one of claims 1 to 4, further comprising a machine learning component configured to analyze the packet metadata and provide inferences based on the analysis thereof.

6. The network server according to claim 5, further comprising a policy component configured to generate the policy rules based on the aforementioned reasoning.

7. The network server according to claim 5 or 6, wherein the machine learning component includes a graphics processing unit.

8. The aforementioned network server is Providing the aforementioned packet metadata to the remote server, A network server according to any one of claims 1 to 7, configured to receive the policy rule from the remote server in response to the provision of the packet metadata.

9. The network server according to any one of claims 1 to 8, wherein the network interface component is configured to receive the network packets at a variable rate.

10. The network server according to any one of claims 1 to 9, wherein the network interface component and the data processing unit are communicatively coupled via a communication bus.

11. The network server according to any one of claims 1 to 10, wherein the network interface component is a smart network interface card.

12. A non-temporary computer-readable storage medium for storing one or more instruction sets configured to be executed by a computing system having a control circuit and memory, wherein the one or more instruction sets are The network interface component allows for the real-time acquisition of multiple network packets from the router device, Extracting packet metadata from the multiple network packets via a data processing unit, Based on the analysis of the aforementioned packet metadata, a policy rule is generated, A non-temporary computer-readable storage medium containing instructions for providing policy rules to the router device via a policy component.

13. The non-temporary computer-readable storage medium according to claim 12, wherein the one or more instruction sets further include instructions for obtaining operational information from the router device, and the policy rules further generate based on an analysis of the operational information.

14. The non-temporary computer-readable storage medium according to claim 13, wherein the operation information includes one or more of the following: information relating to the operating status of the router device, information relating to the network status detected by the router device, and information relating to the hardware and / or software of the router device.

15. The non-temporary computer-readable storage medium according to any one of claims 12 to 14, further comprising instructions for providing inference via a machine learning component by analyzing the packet metadata, wherein the policy rules are generated based on the inference.

16. It is a method, The network interface component allows for the real-time acquisition of multiple network packets from the router device, Extracting packet metadata from the multiple network packets via a data processing unit, Based on the analysis of the aforementioned packet metadata, a policy rule is generated, A non-temporary computer-readable storage medium containing instructions for providing policy rules to the router device via a policy component.

17. The method according to claim 16, further comprising obtaining operational information from the router device, wherein the policy rules are further generated based on an analysis of the operational information.

18. The method according to claim 17, wherein the operation information includes one or more of the following: information relating to the operating state of the router device, information relating to the network state detected by the router device, and information relating to the hardware and / or software of the router device.

19. The method according to any one of claims 16 to 18, further comprising providing inference via a machine learning component by analyzing the packet metadata, wherein the policy rule is generated based on the inference.

20. The method according to any one of claims 16 to 19, wherein the plurality of network packets are acquired at a variable rate.

21. An anomaly detection method, wherein the method is The process involves acquiring input network data from a network device, wherein the network data includes operational information and packet metadata for the network device. Classifying the input network data using one or more machine learning models, including identifying anomalous network data from the input network data; A method comprising generating policy rules based on the aforementioned abnormal network data.

22. The method according to claim 21, wherein the one or more machine learning models include a support vector machine (SVM) model.

23. The method according to claim 21 or 22, wherein the one or more machine learning models include a logistic regression model, a random forest model, or a k-nearest neighbors (KNN) model.

24. The method according to any one of claims 21 to 23, wherein the one or more machine learning models include unsupervised deep learning models.

25. The method according to any one of claims 21 to 24, wherein the one or more machine learning models include an SVM model and an unsupervised model.

26. The method according to claim 25, wherein the SVM model is trained on pre-labeled data, and the unsupervised model is configured to learn autonomously.

27. The method according to claim 25 or 26, wherein the unsupervised model is configured to learn through a series of rewards and penalties.

28. The method according to any one of claims 21 to 27, wherein the one or more machine learning models include a model for network traffic analysis, a model for network security analysis, and / or a model for network maintenance analysis.

29. The method according to any one of claims 21 to 28, wherein the classification of the input network data is performed in real time.

30. The method according to any one of claims 21 to 29, wherein the input network data corresponds to changes in the Border Gateway Protocol (BGP).

31. The method according to any one of claims 21 to 30, wherein the input network data includes protocol metadata for one or more network packets.

32. The method according to any one of claims 21 to 31, wherein classifying the input network data includes performing a two-class classification.

33. The method according to any one of claims 21 to 32, further comprising obtaining a classification hyperplane for the one or more machine learning models by training the one or more machine learning models using labeled training data.

34. The method described above is the method according to any one of claims 21 to 33, which is performed in the network device.

35. The method according to any one of claims 21 to 34, wherein classifying the input network data includes performing a radial basis function to linearly separate the input network data.

36. The method according to any one of claims 21 to 35, wherein the operation information includes one or more of the following: information relating to the operating state of the network device, information relating to the network state detected by the network device, and information relating to the hardware and / or software of the network device.

37. A method for mitigating abnormalities, wherein the method is Obtaining metadata for multiple network packets, To obtain operational information for one or more network devices, By analyzing the acquired metadata, anomalies in the multiple network packets can be detected, Based on the detected anomalies, policy rules are generated without human intervention, A method comprising applying the policy rule to one or more network devices.

38. The method according to claim 37, wherein the policy rule is applied via each worker node implemented in each of the one or more network devices.

39. The method according to claim 37 or claim 38, wherein the metadata includes packet header information.

40. The method according to any one of claims 37 to 39, wherein the plurality of network packets include one or more control protocol packets.

41. The method according to any one of claims 37 to 40, further comprising generating a time-series profile of network elements and network operations, wherein the anomaly is detected using the time-series profile.

42. The method according to any one of claims 37 to 41, wherein the anomaly is detected using pattern matching.

43. The method according to any one of claims 37 to 41, wherein the anomaly is detected using one or more machine learning models.

44. The method according to any one of claims 37 to 43, wherein the metadata is acquired via a network collector device.

45. The method according to any one of claims 37 to 44, wherein the abnormality is detected via an operating device.

46. The method according to any one of claims 37 to 45, wherein the policy rule is generated via an operating device.

47. The method according to any one of claims 37 to 46, wherein the aforementioned abnormality corresponds to a faulty network component.

48. The aforementioned anomaly corresponds to malicious activity, according to any one of claims 37 to 46.

49. The method according to any one of claims 37 to 46, wherein the abnormality includes a routing abnormality.

50. The method according to any one of claims 37 to 49, wherein the network packet corresponds to an optical network, a microwave-based network, a cellular network, and / or an internet network.

51. The method according to any one of claims 37 to 50, wherein the policy rule includes an evaluation component and an action component.

52. The method according to any one of claims 37 to 51, wherein generating the policy rules includes extending an existing set of policy rules.

53. The method according to any one of claims 37 to 52, wherein the operation information includes one or more of the following: information relating to the operating state of one or more network devices, information relating to the network state detected by one or more network devices, and information relating to the hardware and / or software of one or more network devices.

54. A method for applying a policy, wherein the method is In a router device including memory and control circuits, Applying one or more policy rules to the aforementioned router device, While applying one or more of the aforementioned policy rules, The policy agent receives updated policy rules from the policy server, A method comprising implementing the updated policy rule by adjusting the data plane of the router device via the policy agent.

55. The method according to claim 54, wherein the policy agent is implemented as a worker node.

56. The method according to claim 54, wherein the policy agent is implemented within the control plane of the router device.

57. The method according to claim 54, wherein the policy agent is implemented as a Docker container.

58. The method according to any one of claims 54 to 57, further comprising subscribing to policy messages from the policy server via the policy agent, wherein one or more policy rules are received via the policy messages.

59. The method according to any one of claims 54 to 58, wherein the one or more policy rules include one or more traffic rules, routing changes, and access control lists.

60. The method according to any one of claims 54 to 59, wherein the router device is a network element deployed within a service provider network.

61. The method according to any one of claims 54 to 60, wherein adjusting the data plane includes writing further policy rules to the content-addressable memory of the router device.

62. A non-temporary computer-readable storage medium that, when executed by a computing system, includes instructions that cause the computing system to perform or trigger the performance of any of the methods described in claims 16 to 61.

63. A computing system, One or more processors, A computing system including a memory containing instructions that, when executed in one or more processors, cause the execution of the method according to any one of claims 16 to 61.

Images