Apparatus, system and method for enhanced network monitoring, data reporting, and data processing
Abstract
An apparatus, comprising: a plurality of state machines (1204) controlled by microcode, at least one of the plurality of state machines (1204) controlled by microcode being configured to generate first statistical data measured in each of a plurality of time intervals of a first time granularity based on the network data included in each of a plurality of data streams (695) that run the at least one of the plurality of state machines (1204) controlled by microcode; the apparatus being characterized by data reduction logic (700) configured to receive the first statistical data, and to obtain second statistical data that have a reduced volume with respect to a volume of the first statistical data depending on the performance of a mathematical operation on the first statistical data, the second statistical data being associated with each of the plurality of time intervals of a second time granularity, the first granularity of time being finer than the second granularity of time; and transmission logic (702), without any request, configured to send the second statistical data through a network regardless of a real-time request from the network.
Term
7.2 yearsto projected expiry
Projected expiry 6 December 2033, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
15 claims: 2 independent, 13 dependent
- 1ES 2 652 292 T3 REIVINDICACIONES 1. Un aparato, que comprende:una pluralidad de máquinas (1204) de estado controladas por microcódigo, estando configurada al menos una de la pluralidad de máquinas (1204) de estado controladas por microcódigo para generar primeros datos estadísticos medidos en cada uno de una pluralidad de intervalos de tiempo de una primera granularidad de tiempo en función de los datos de la red incluidos en cada uno de una pluralidad de flujos (695) de datos que recorren la al menos una de la pluralidad de máquinas (1204) de estado controladas por microcódigo;estando el aparato caracterizado por lógica (700) de reducción de datos configurada para recibir los primeros datos estadísticos, y para obtener segundos datos estadísticos que tienen un volumen reducido con respecto a un volumen de los primeros datos estadísticos en función del desempeño de una operación matemática sobre los primeros datos estadísticos, estando asociados los segundos datos estadísticos con cada uno de la pluralidad de intervalos de tiempo de una segunda granularidad de tiempo, siendo más fina la primera granularidad de tiempo que la segunda granularidad de tiempo;y lógica (702) de transmisión, sin que medie solicitud, configurada para enviar los segundos datos estadísticos a través de una red con independencia de una solicitud en tiempo real procedente de la red.
- 2El aparato de la reivindicación 1, en el que la lógica (700) de reducción de datos es configurable para reducir el volumen de los primeros datos estadísticos para obtener los segundos datos estadísticos, de forma que se mantenga una indicación de una función de los primeros datos estadísticos en los segundos datos estadísticos, en el que la función quedaría enmascarada si los segundos datos estadísticos estuviesen basados en una agregación de los primeros datos estadísticos en cada uno de la pluralidad de intervalos de tiempo de la segunda granularidad de tiempo.
- 3El aparato de la reivindicación 2, en el que:la operación matemática incluye un máximo;y los segundos datos estadísticos incluyen un resultado de la operación matemática aplicada a los primeros datos estadísticos en cada uno de la pluralidad de intervalos de tiempo de la segunda granularidad de tiempo, de forma que una indicación de variaciones incluidas en los primeros datos estadísticos que son sustancialmente mayores que un valor medio de los primeros datos estadísticos sean visibles tras la representación visual de los segundos datos estadísticos.
- 4El aparato de la reivindicación 2, en el que:la función en los primeros datos estadísticos incluye un pico y un valle, y está indicada por un subconjunto de los primeros datos estadísticos;el pico se indica mediante una porción del subconjunto de los primeros datos estadísticos;y el valle se indica mediante una porción restante del subconjunto de los primeros datos estadísticos.
- 5El aparato de la reivindicación 1, en el que un volumen de los segundos datos estadísticos es reducido al menos diez veces con respecto a un volumen de los primeros datos estadísticos.
- 6El aparato de la reivindicación 1, en el que la operación matemática incluye al menos uno de un mínimo, un máximo y una media.
- 7El aparato de la reivindicación 1, en el que la operación matemática incluye al menos uno de una convolución, una media móvil, una suma de los cuadrados, una operación de filtrado lineal y una operación de filtrado no lineal.
- 8El aparato de la reivindicación 1, en el que la lógica (702) de transmisión, sin que medie solicitud, es configurable para generar uno o más paquetes que incluyen los segundos datos estadísticos e información de direcciones asociada con un dispositivo ubicado en otro lugar en la red.
- 9El aparato de la reivindicación 1, en el que la lógica (702) de transmisión, sin que medie solicitud, es configurable para anunciar la pluralidad de flujos (695) de datos a un dispositivo ubicado en otro lugar en la red.
- 10El aparato de la reivindicación 1, en el que:la pluralidad de flujos (695) de datos recorre un recorrido de los datos que se extiende a través de una porción del aparato;y ES 2 652 292 T3 la lógica (702) de transmisión, sin que medie solicitud, es operable para enviar, sin que haya solicitud, los segundos datos estadísticos mediante comunicaciones que recorren al menos una porción del recorrido de los datos.
- 11El aparato de la reivindicación 1, en el que la solicitud en tiempo real es un sondeo procedente de un dispositivo ubicado en otro lugar en la red. 5
- 12El aparato de la reivindicación 1, que comprende, además, lógica (706) de análisis del tiempo de espera de la red y de la fluctuación configurada para recibir información del tiempo de espera de la red procedente de al menos una de la pluralidad de máquinas (1204) de estado controladas por microcódigo.
- 13El aparato de cualquiera de las reivindicaciones 1-12, que comprende, además:lógica (704) de generación de alertas configurada para generar una indicación de alerta asociada con el al menos 10 uno de la pluralidad de flujos (695) de datos procesando los primeros datos estadísticos para determinar si los primeros datos estadísticos implican una característica asociada con la alerta;estando configurada la lógica (702) de transmisión, sin que medie solicitud, además, para enviar la indicación de alerta a través de la red con independencia de una solicitud de la red. 15
- 14El aparato de la reivindicación 13, en el que la característica se indica en función de la aparición de un patrón de bits en los datos de la red.
- 15El aparato de la reivindicación 13, en el que la característica se indica en función de la aparición de un patrón de variación en una velocidad de transferencia de datos asociada con los datos de la red.
Independent claims15
158 paragraphs in 5 sections, as filed
ES 2 652 292 T3
DESCRIPTION
Apparatus, System, and Procedure for Enhanced Network Monitoring, Data Communication, and Data Processing
Field of the invention
The present invention relates generally to network monitoring and data analysis. More particularly, the present invention relates to improved monitoring and searching of devices distributed over a network, improved communication and data processing in a network, reducing data to facilitate the identification and presentation of data variations, and a improved communication and measurement of performance data.
Background of the invention
The widespread use of computer networks to increase productivity and to facilitate communications makes network traffic monitoring, network analysis, and network security major concerns. The traffic load and the number of data flows traversing networks and data centers are increasing rapidly, resulting in a rapidly increasing number of data flows, services, and performance counters that have to be monitored by network management architectures. For some packet data streams, it may be sufficient to monitor per-stream performance metrics, such as transmitted or received bytes, in a time granularity of one second. This is a common configuration for typical network management architectures such as Simple Network Management Protocol (SNMP) architectures. However, for other flows data packet , it may be important to monitor the per stream performance metric at finer time granularity, such as 1 millisecond or 10 milliseconds, since there are phenomena that can significantly impact significant is the quality of service of a stream that may be visible at these finer time granularities, but is not visible at a time granularity of one second. Typical SNMP stacks may not be designed for this level, and may not scale well to it, of fine-grained monitoring on a large number of network devices that may be deployed around the world. In addition, typical network management systems can provide a user interface that enables flexible efficient analysis of large amounts of network monitoring data.
It is against this background that the need arose to develop the apparatus, system, and method for improved network monitoring, data communication, and data processing described herein.
US 2005/0120054 A1 discloses a dynamic learning procedure and an adaptive normal behavior profile (NBP) architecture to provide rapid protection of business applications. The adaptive architecture of NBP includes a plurality of profile elements. Each profile element includes a plurality of profile properties that contain the descriptive values of the respective element. An application-level security system can identify and prevent attacks targeting business applications by matching application events against at least a single profile element in the adaptive NBP.
Summary of the invention
The present invention is defined by independent claim 1. The dependent claims relate to optional features of some embodiments of the invention. In order to determine the degree of protection, any element that is equivalent to an element specified in the claims will be duly taken into account.
One aspect of the disclosure relates to a system that includes a first device and a second device configured to monitor a plurality of data streams traversing the second device. The second device is configured to collect statistics associated with the plurality of data streams, and includes traffic analysis logic that is configured to augment the plurality of data streams with data that includes statistical information based on statistics and address information. associated with the first device. The first device is configured to receive the data. The traffic analysis logic is operable to send the statistical information to the first device independent of a real-time request for at least a portion of the statistical information from the first device. The traffic analysis logic is configurable based on at least the address information.
Another aspect of the disclosure relates to a system that includes a first device and a second device. The first device includes traffic analysis logic configured to process first data measured in each of a plurality of time intervals of a first time granularity to obtain second data associated with each of a plurality of time intervals of a second granularity. of time. The first time granularity is finer than the second time granularity. The second device is configured to receive and display the second data. The analysis logic of
ES 2 652 292 T3 traffic is configurable sensitively to the second device to reduce a volume of the first data to obtain the second data, so that an indication of a characteristic in the first data remains in the second data, leaving the characteristic masked if the second data were based on an aggregation of the first data in each of the plurality of time intervals of the second time granularity.
One aspect of the invention relates to an apparatus. In one embodiment, the apparatus includes a plurality of state machines controlled by microcode, data reduction logic, and transmission logic, without prompting. At least one of the microcode controlled state machines is configured to generate first statistical data measured in each of a plurality of time intervals of a first time granularity as a function of network data included in each of a plurality of streams data traversing the at least one of the plurality of microcode controlled state machines. The data reduction logic is configured to receive the first statistical data, and to obtain second statistical data that has a reduced volume relative to a volume of the first statistical data based on the performance of a mathematical operation on the first statistical data. The second statistical data is associated with each of the plurality of time intervals of a second time granularity. The first time granularity is finer than the second time granularity. The transmission logic, without request, is configured to send the second statistical data through a network independently of a real-time request from the network.
According to another aspect of the disclosure, the apparatus includes a plurality of state machines controlled by microcode, alert generation logic, and transmission logic, without prompting. At least one of the plurality of microcode controlled state machines is configured to generate statistical data measured in each of a plurality of time intervals based on the network data included in each of a plurality of data streams that traverse the at least one of the plurality of microcode controlled state machines. The alert generation logic is configured to generate an alert indication associated with the at least one of the plurality of data streams by processing the statistical data to determine whether the statistical data implies a characteristic associated with the alert. The transmission logic, without a request, is configured to send the alert indication over a network independent of a request from the network.
A further aspect of the disclosure relates to a system for network monitoring and network traffic analysis that includes a plurality of network devices and a management station. Each of the plurality of network devices is associated with corresponding ports of a plurality of ports. Each of the plurality of network devices is configured to determine the network traffic analysis data associated with a characteristic of the network data traversing each of the plurality of ports. The management station is configured to determine a classification of the plurality of ports based on network traffic analysis data in response to a search request involving the feature, and is configured to display the plurality of ports in classification function.
A further aspect of the disclosure relates to a system that includes a plurality of first devices, each of the plurality of first devices being configured with a corresponding set of ports included in a plurality of ports. Each of the plurality of first devices is configured to determine second data based on the first data associated with each of the corresponding set of ports. The system also includes a second device coupled with the plurality of first devices in a network. The second device is configured to search the plurality of ports based on an input search criteria, to classify at least two of the plurality of ports based on the second data and the input search criteria, and to visually represent the at least two of the plurality of ports in a ranked order.
Other aspects and embodiments of the invention are also contemplated. The above summary and the following detailed description are not intended to restrict the invention to any particular embodiment but are merely intended to describe some embodiments of the invention.
Brief description of the drawings
For a better understanding of the nature and objects of the invention, reference should be made to the following detailed description taken in conjunction with the accompanying drawings, in which:
FIG. 1 illustrates an example of a network with representative locations where a network device can be connected, according to an embodiment of the invention;
FIG. 2 illustrates a system for network monitoring and network traffic analysis, according to an embodiment of the invention;
ES 2 652 292 T3 FIGURES 3A to 3C illustrate examples of visual representations showing a search request involving a network traffic analysis data characteristic, and a port classification in response to the search request, according to an embodiment of the invention;
FIG. 4A illustrates an example of network operation data with a granularity of one second in which a characteristic of the data traveling the network device is masked, according to the prior art;
FIG. 4B illustrates an example of network operation data with millisecond granularity in which a characteristic of the data traversing a network device is maintained, according to an embodiment of the invention;
FIG. 4C illustrates an example of network traffic analysis data having a reduced volume compared to the network performance data of FIG. 4B while maintaining an indication of the characteristic of the data traversing the network device, according to an embodiment of the invention;
FIG. 5 illustrates an example of a network with representative locations where time stamp values associated with data streams can be observed, according to one embodiment of the invention;
FIG. 6 illustrates a logic block diagram of a system for managing a network device, according to an embodiment of the invention;
FIG. 7 illustrates a logic block diagram of the traffic analysis logic included in the network device, according to an embodiment of the invention;
FIG. 8 illustrates a logic block diagram of an architecture of one embodiment of the invention;
FIG. 9 illustrates the use of the architecture of FIG. 8 for bi-directional applications, according to one embodiment of the invention;
FIG. 10 illustrates the internal architecture of the distribution circuit shown in FIG. 8, according to an embodiment of the invention;
FIG. 11 illustrates the internal architecture of the rule engine shown in FIG. 8, based on a microcode controlled state machine, according to an embodiment of the invention;
FIG. 12 illustrates an example of a microcode instruction execution sequence for implementing a comparison rule, according to an embodiment of the invention;
FIG. 13 illustrates an example of the internal architecture of the condition logic shown in FIG. 11, according to an embodiment of the invention; and FIG. 14 illustrates a logic block diagram of an interface between rule engines and their associated addressing modules, in accordance with one embodiment of the invention.
Detailed description of the invention
FIG. 1 illustrates an example of a network 100 with representative locations 120 where a network device can be connected, in accordance with one embodiment of the invention. Network 100 is an example of a network that can be deployed in a data center to connect clients to the Internet. The connections shown in FIG. 1 are bi-directional unless otherwise noted. In one embodiment, the network 100 includes central switches 102, peripheral routing devices 104, and access switches 106. Core switches 102 provide Internet connectivity over multiple high capacity links 110, such as 10 Gigabit Ethernet, 10GEC 802.1Q, and / or OC-192 packet over SONET links. Central switches 102 may be connected to each other by means of multiple high capacity links 111, such as to support high availability. Central switches 102 may also be connected to peripheral routing devices 104 via multiple links 112. Peripheral routing devices 104 may be connected to access switches 106 via multiple links 114. Links 112 and links 114 may be high capacity links or they may be lower capacity links, such as 1 Gigabit Ethernet and / or OC-48 packet over SONET links. Clients can connect to access switches 106 through physical and / or logical ports 116.
FIG. 2 illustrates a system 600 for network monitoring and network analysis, in accordance with one embodiment of the invention. System 600 includes network devices 602A-602N that monitor and perform analysis, such as network traffic. Network traffic that is monitored and analyzed by network devices 602 can enter network devices 602 through interfaces 612A-612Z. After monitoring and analysis by network devices 602, network traffic can leave network devices through 4
ES 2 652 292 T3 Interfaces 612 if Interfaces 612 are bldlrecclonal, or through other Interfaces (not shown) if Interfaces 612 are unidirectional. Each of the network devices 602 can have a large number of high capacity Interfaces 612, such as 32 10 Gigabit Network Interfaces.
In one embodiment, each of the network devices 602 can monitor and analyze the traffic on a corresponding network 100, such as a data center network. With reference to FIG. 1, in one example Interfaces 612 may be connected to network 100 at corresponding locations of locations 120. Each of Interfaces 612 may monitor traffic from a link in network 100. For example, in FIG. 1, one or more network devices 602 may monitor traffic on links 112 and 114.
Network devices 602 are connected to a management station 604 in a network 606. Network 606 can be a wide area network, a local area network, or a combination of wide area and / or local area networks. For example, network 606 may represent a network that spans a large geographic area. Management station 604 can monitor, collect, and display traffic analysis data from network devices 602, and can provide control commands to network devices 602. In this way, the management station can enable a single location operator to monitor and control network devices 602 deployed throughout the world.
In one embodiment, the management station 604 may receive a search request (search criteria) as input. The search request may involve a characteristic of the network data flowing through one or more ports associated with the network devices 602. The port (s) may be physical ports of the network devices 602, and may correspond to one or more of the Interfaces 612. Alternatively, the one or more ports can be logical ports in a single traffic stream. The characteristic of network data can take various forms known to one of ordinary skill in the art related to network data. For example, the characteristic can be indicated as a function of the appearance of a bit pattern in the network data and / or as a function of the appearance of a pattern of variation in a data transfer rate associated with the network data. Alternatively or additionally, the search request may involve an operational characteristic of the one or more ports, or an operational characteristic of one or more of the network devices 602. The operational feature may take various forms known to one of ordinary skill in the art related to the operability of network devices. For example, the operational characteristic may be based on the existence of an alarm condition of a particular degree of severity, or it may be based on configuration information, such as hardware, software, and / or service settings. to the client.
In response to the search request, management station 604 may process network analysis data received from network devices 602 via network 606. Management station 604 may determine which ports, interfaces 612, and / or Network devices 602 are Implicated by the search request, and you can display these ports, interfaces 612, and / or network devices 602, such as in a list or table. In one embodiment, the management station 604 can classify the ports, interfaces 612, and / or network devices 602 that are involved by the search request, and can display ports, interfaces 612, and / or devices 602. network in the sorted order (see the following discussion with reference to FIGURES 3A to 3C). Searching and sorting can be carried out based on any algorithm and / or criteria known to a person of a normal level of skill in the art. For example, in response to a search request for ports with network data traversing ports that have a particular characteristic, the management station 604 may select a subset of ports among the network devices 602 for which the network data The traversing ports have the characteristic, and can represent that subset of ports. The subset of ports can be displayed in ranked order based on a number of times the feature has been detected in the network data traversing the subset of ports.
Additionally, in one embodiment, the management station 604 may re-visualize the ports, Interfaces 612, and / or network devices 602 following a change in classification due to dynamic variations in network analysis data. For example, the management station 604 can dynamically reshape the visual representation of the ports based on real-time variations in the number of times a feature has been detected in the network data traversing the ports.
As used herein, "network analysis data" refers broadly to both network traffic analysis data associated with data traversing one or more network devices (such as network devices 602). , and other network-related data associated with the operational characteristics of one or more network ports, interfaces, and / or devices. The network traffic data may include, for example, data associated with the evaluation of signature-based and / or behavioral rules applied to the network data traversing one or more of the network devices 602. The network traffic analysis data can include statistics (such as performance data) associated with the network data. Examples of these statistics include data related to the quantity of network data and / or the quality of network data, the examples of data quality statistics may include numbers of errors detected in data that travels a port, and the round-trip network wait time associated with data received at a port. Alternatively or additionally, the network traffic analysis data may include data derived from processing
ES 2 652 292 T3 additional data associated with the evaluation of the rules applied to the network data, or the statistics associated with the network data. This additional processing can be performed by the network devices 602 to enhance the scaling of the network management architecture, as described below.
Network devices 602 can effectively perform network traffic monitoring, filtering, aggregation, reiteration, balancing, time stamping, and / or modification of traffic in a unified architecture, in rules function that can be very granular (such as granular down to the bit) anywhere in the network traffic, while at the same time they act as a "stop in the thread" minimizing the disruption of network traffic introduced by network devices 602. By performing at least this wide variety of functions, network devices 602 can obtain network analysis data that network devices 602 can provide to management station 604 to support a wide variety of page requests received by management station 604. These search requests can be related to a wide range of characteristics of network traffic and / or network devices. The search and sort capability of the management station 604 has a compelling combination of advantages, because this capability can be among network devices 602 deployed throughout the world, it can be in this wide range of features, and it can have account for dynamic changes in search results and / or search results ranking due to dynamic variations in network analysis data. The search and classification capabilities of the management station 604 can also allow flexible, efficient, and context-based analysis and filtering of the large amount of network analysis data available at the management station 604.
Network devices 602 can collect network traffic analysis data in various ways. For example, a network device 602 may apply one or more rules to select a data flow (logical port), such as based on a packet header field such as an IP address or an upper layer identifier, such as a Transmission Control Protocol (TCP) port. Alternatively or additionally, network device 602 may collect statistics associated with network traffic, such as for data streams (logical ports) and / or physical data ports. Alternatively or additionally, the network device 602 may insert and / or remove a timestamp from one or more packets included in the data stream as part of the network data stream timeout measurement. (see the following discussion with reference to FIG. 5). The insertion and removal of the timestamp can be carried out on the fly, without capturing the data packets, and without copying the data packets. The search request can be associated with any or all of these types of network traffic analysis data.
A rule is a specific criterion used by the apparatus to determine whether it should react to a unit of data, such as a packet included in a data stream. One type of rule is signature-based. Signatures are sequences of bits anywhere in the digital traffic content that indicate a characteristic of the traffic of interest to the device. The bit sequences can be completely invariant, or they can contain portions that are wildcards not essential to the evaluation of the rule. A signature could appear in the header or payload of individual packets on the network, or in a sequence of packets. A signature can span one or more packet headers and corresponding payloads, and deep packet inspection is used to discover such signatures. A stream inspection is used to discover signatures in a sequence of packets. Both types of inspection are used for complete visibility of various types of network traffic.
A second type of rule is behavioral. Two types of behavior rules are local and network-based behavior rules. It is contemplated that local behavior rules can be used to detect changes that can be measured locally in the apparatus. These changes include, without limitation, changes in the volume of traffic or in the balance of inbound and outbound traffic, such as requests and responses, passing through the appliance. Network-based behavior rules can be used to detect changes in the network that can be measured in conjunction with other network devices, including, without limitation, the appliance. An example of such a rule is the total volume of traffic averaged at multiple points on the network over a specific period of time compared to a maximum threshold. Another example is the total number of events of a specific type, such as network error indications, that have occurred across the network over a specific period of time, again compared to a maximum threshold. Monitoring the collected statistics for a rule evaluation can be important, for example, because a malfunction in the network can be detected based on its impact on the behavior or performance of the network. Alternatively or additionally, a new type of attack can be detected based on its impact on network performance or behavior, even when its signature is unknown.
A third type of rule is both behavioral and signature-based. An example of such a rule is the total number of packets containing a specific signature that have passed through a network device 602 during a specific period of time during the day compared to a maximum and / or minimum threshold. The logical port to which a packet (or packets, such as packets included in a data flow) belongs can be determined by applying to the packet (or packets, such as packets included in a data flow) a rule such as a rule based on the signature, a behavior rule, or a combination of behavior and signature-based rules.
ES 2 652 292 T3
In addition to rule enforcement and statistics collection, network devices 602 may perform additional functions to enhance scalable communication of network traffic analysis data on network 606. In particular, data processing and analysis functions can be divided between network devices 602 and management station 604, such that network devices 602 carry out significant portions of these functions locally, such as on hardware. , in reconfigurable logic and / or in firmware. For example, network devices 602 can enhance statistics collected by network devices 602, such as statistics associated with data streams, to reduce the volume of network traffic analysis data that must be communicated to the management station 604 while maintaining an indication of a characteristic (function) of the data streams shown in the collected statistics (see the discussion with reference to the following FIGURES 4A to 4C). In one embodiment, the search and classification of ports, interfaces 612, and / or network devices 602 may be based on network traffic analysis data that has been reduced as described above.
Alternatively or additionally, network devices 602 may process statistics and / or rule-based information collected by network devices 602, and based on this processing may generate an alert indication for management station 604. The alert indication may be associated with corresponding indications of the ports, the interfaces 612 and / or the network devices 602 as a function of the detection of a characteristic in the network data that the corresponding indications of the ports, of the interfaces 612 and / or network devices 602. In one embodiment, the search and classification of ports, interfaces 612, and / or network devices 602 may be based on whether the alert indication is present for each of the ports, interfaces 612, and / or or from network 602 devices.
Alternatively or additionally, network devices 602 may perform mathematical operations on statistics and / or rule-based information collected by network devices 602. In one embodiment, these mathematical operations can include at least one of a minimum, a maximum, a mean, a convolution, a moving average, a sum of squares, a linear filter operation, and a non-linear filter operation. In one embodiment, the search and classification of ports, interfaces 612 and / or network devices 602 may be based on a result of at least one of these mathematical operations on statistics and / or rules-based information. associated with network data.
The above-described performance of significant portions of data analysis and function processing at network devices 602 rather than management station 604 has several advantages. Reducing the volume of network traffic analysis data to be communicated to the management station 604 can significantly reduce the per-flow network bandwidth overhead associated with managing the network. This can be important as the traffic load and the number of data flows through networks and data centers are increasing rapidly, resulting in a rapidly increasing number of performance counters that have to be monitored by networks. network management architectures. In addition, the processing of statistics and / or rule-based information collected by the network devices 602 on the network devices 602 can significantly reduce the processing load on the management station 604. This can reduce the processing and memory requirements in the management station 604, can simplify the software that runs in the management station 604, and can speed up the operation of the management station 604.
In one embodiment, network analysis data can be communicated to management station 604 by transmission-based management, without prompting (see the following discussion with reference to FIG. 6). Management based on transmission, without request, can also significantly reduce network bandwidth overhead by eliminating the overhead due to probes in management protocols based on reception, without request, such as Simple Network Management Protocol (SNMP).
Furthermore, in today's networks, data flows represent a wide variety of services with a variety of performance requirements. For example, for some data packet streams, it may be sufficient to monitor performance metrics per stream, such as bytes transmitted or received, with a time granularity of one second. This is a common configuration for typical network management architectures, such as SNMP architectures. However, for other packet data streams, it may be important to monitor the performance metrics per stream with finer time granularity, such as 1 milliseconds or 10 milliseconds, as there are phenomena that can have a significant impact on the quality of service of a stream that may be visible at these finer time granularities, but is not visible at a time granularity of one second. Typical SNMP stacks may not be designed for this level, and may not scale well to it, of fine-grained monitoring. In addition, streaming-based management architectures, without demand, by eliminating the polling overhead associated with SNMP, can provide this finer-grained stream-based monitoring with greater efficiency.
FIGURES 3A to 3C illustrate examples of displays showing a search request involving a characteristic of the network traffic analysis data, and a port classification in response to the search request, in accordance with an embodiment of the invention. . FIG. 3A illustrates a visual representation showing a search term, network devices, and ports on which a particular string occurs on the
ES 2 652 292 T3 data traversing the ports, and a classification of the ports as a function of the number of occurrences of the chain, according to an embodiment of the invention. In the example of FIG. 3A, the string is "AQUA". The network device identifier and / or the port identifier may be, for example, an IP address, a MAC address, a manufacturer identifier, or a user-defined identifier, but is not limited to these types of identifiers.
FIG. 3B illustrates a visual representation showing a search term, network devices and ports in which a particular condition (such as a microburst) occurs in the data traversing the ports, and a classification of the ports based on the number of occurrences of the condition, according to an embodiment of the invention. In the example of FIG. 3B, the condition is a microburst. The network device identifier and / or port identifier may be, for example, an IP address, MAC address, manufacturer identifier, or user-defined identifier, but is not limited to these types of identifiers.
FIG. 3C illustrates a visual representation showing a search term, network devices, and ports for which a measured data transfer rate traversed by the ports exceeds a particular threshold, and a ranking of the ports by data transfer rate, based on an embodiment of the invention. In the example of FIG. 3C, the threshold is 1 Gbps. The network device identifier and / or port identifier may be, for example, an IP address, MAC address, manufacturer identifier, or user-defined identifier, but is not limited to these types of identifiers.
In one embodiment, referring to FIG. two, one or more of the network devices 602 may include traffic analysis logic configured to process first data (such as first non-reduced statistical data which may include first non-reduced network performance data) measured at time intervals of a first granularity of time to get second data (such as second reduced statistics that may include second reduced network performance data) associated with the time intervals of a second time granularity. This second data may be included in the network traffic analysis data provided to the management station 604 by the one or more network devices 602. The first time granularity can be finer than the second time granularity. The management station 604 may be configured to receive the second data from the one or more network devices 602, and to display the second data. The traffic analysis logic is responsibly configurable to the management station 604 to reduce a volume of the first data to obtain the second data, so that an indication of a function (characteristic) of the second data is maintained in the second data. first data, the function being masked if the second data were based on an aggregation of the first data in each of the time intervals of the second time granularity. An example of this data reduction is provided in FIGS. 4A to 4C below.
FIG. 4A illustrates an example of non-reduced network performance data 640 with a second granularity in which a function of the data traveling through the network device 602 (see FIG. 2) is masked, in accordance with the prior art. The non-reduced network performance data 640 is shown as a bandwidth (number of bits that can flow in a given time) of a data stream produced by an Internet Protocol Television (IPTV) encoder measured as a time function. For a second granularity, notable functions are masked in the data (which are visible in FIG. 4B) because each data sample in the non-reduced network performance data 640 may be based on an aggregate amount of data transmitted over a significantly longer time interval than the duration of each of the notable functions in the data. that are masked.
FIG. 4B illustrates an example of non-reduced network performance data 650 with millisecond granularity in which a function 658 of data traversing network device 602 is maintained (see FIG. 2), according to one embodiment of the invention. Unreduced network performance data 650 is displayed as bandwidth (number of data bits that can flow in a given time) of a data stream output by a measured Internet Protocol Television (IPTV) encoder as a function of time. The non-reduced network performance data 650 includes function 658, which may be indicated as a subset of the non-reduced network performance data 650. The function 658 may include a peak 652, during which the bandwidth per millisecond of the non-reduced network performance data 650 is substantially greater than an average bandwidth of the non-reduced network performance data 650. Peak 652 is preceded by a trough 654, during which the bandwidth per millisecond of the non-reduced data 650 of network performance is substantially less than an average bandwidth of the non-reduced data 650 of network performance . Function 658 can also include valley 654. Alternatively, function 658 can only include peak 652. There may be other 656 drops in the network performance unreduced data 650, but the time span of the 654 valley may be significantly greater than the time span of the other 656 drops. Function 658 may occur in the network performance unreduced data 650 due, for example, to an undesirable "hiccup" in the data stream output by the IPTV encoder, during which the IPTV encoder first it fails to transmit data (during valley 654), then bursts (during peak 652) to maintain the average bandwidth of the data not reduced 650 of network performance. This phenomenon is an example of a microburst, which is a short period during which the instantaneous traffic load on a communication channel is significantly higher and / or less than a typical traffic load on the communication channel.
ES 2 652 292 T3 communications. The communications channel may be a physical channel (associated with a physical port) or a logical channel (associated with a flow or logical port) that may have a data-carrying capacity portion of the physical channel. Microbursts in a network, such as network 100 (see FIG. 1), can be problematic because, for example, peak 652 can violate capacity limitations in network 100, resulting in packet loss.
FIG. 4C illustrates an example of reduced network performance data 660 having a reduced volume compared to the non-reduced network performance data 650 of FIG. 4B while maintaining an indication of the function 658 of the data traversing the network device 602 (see FIG. 2), in accordance with one embodiment of the invention. The reduced network performance data 660 is shown as bandwidth (number of data bits that can flow in a given time) of a data stream produced by an Internet Protocol Television (IPTV) encoder measured as a time function. The reduced data 660 of network performance has a granularity of one second. The reduced network performance data 660 can be obtained by applying mathematical operations to the non-reduced network performance data 650. In the example of FIG. 4C, the 660A depleted network performance data is the maximum, in 1 second time intervals, of the 1-millisecond granularity samples of the non-depleted 650 network performance data in each of the time intervals of 1 second. In one embodiment, an indication of variations included in the non-reduced network performance data 650 in a 1 second time interval that are substantially greater than an average value of the non-reduced network performance data 650 in the interval 1 second time slots are visible after the visual representation of the reduced network performance data 660A. The 660B reduced network performance data is the average, in 1 second time intervals, of the 1-millisecond granularity samples of the 650 non-reduced network performance data in each of the 1 time intervals second. The 660C reduced network performance data is the minimum, in 1 second time intervals, of the 1 millisecond granularity samples of the 650 non-reduced network performance data in each of the 1 time intervals second. In one embodiment, an indication of variations included in the non-reduced network performance data 650 in a 1 second time interval that is substantially less than an average value of the non-reduced network performance data 650 in the interval 1 second time slots are visible after visual representation of the 660C reduced network performance data. As can be seen from the network performance reduced data 660A, an indication of peak 652 (see FIG. 4b) is maintained in the non-reduced network performance data 650 in the network performance reduced data 660A. network such as peak 662, although a network throughput reduced data volume 660A can be at least 10 times less (in this case, 1000 times less) than a network throughput non-reduced data volume 650. For example, the indication 662 may include a maximum of the non-reduced network performance data 650 in at least one of the 1 second time intervals. In this way, a volume of the network performance depleted data with a granularity of 1 second can be significantly reduced over a volume of non-depleted network performance data with a granularity of 1 millisecond, while maintains an indication 662 of peak 652 in the reduced network performance data.
In one embodiment, the reduced network performance data 660 may include a maximum and minimum of the non-reduced network performance data 650, such that indications of both a peak and a trough in the non-reduced data 650 network performance data are visible behind the visual representation of the reduced network performance data. The mean value of the peak can be at least five times greater than an average of the non-reduced data 650 of network performance in a time interval of 1 second (time granularity of the reduced data 660 of network performance) including peak, and a mean value of the valley can be at least five times less than an average of the unreduced data 650 of network performance in a time interval of 1 second (time granularity of the reduced data 660 of network performance) including the valley.
With reference to FIG. 2, in one embodiment, the traffic analysis logic may be responsively configurable to the management station 604 to vary a time granularity of the reduced network performance data produced by the traffic analysis logic. The traffic analysis logic may be responsively configurable to the management station 604 to include in the reduced network performance data at least one of a minimum, a maximum, and an average of the non-reduced network performance data. network in time intervals of the time granularity of the reduced network performance data.
FIG. 5 illustrates an example of a network 670 with representative locations 672A-672D where timestamp values associated with data streams can be measured, in accordance with one embodiment of the invention. With reference to FIG. 2, the network device 602 may insert a timestamp on, and / or remove from, one or more packets included in a data stream as part of measuring the network timeout for packets included in the data stream. data flow. Packet network timeout is a packet delay introduced by a network. For example, the network timeout excludes delays due to software processing at a source (such as host 674) and at a destination (such as host 676). Network wait time can be measured either on the go (the time from sending a packet by the source to receiving it at the destination, such as from location 672A to location 672D), or at the round trip (the sum of the one-way waiting time from the source to the destination, plus the return waiting time from 9
ES 2 652 292 T3 the destination back to the source, such as the sum of the wait time from location 672A to location 672D plus the wait time back from location 672D to location 672A). The network timeout may be the delay from the time of the start of packet transmission at a sender to the time of the end of packet reception at a receiver. Alternatively, the network timeout may be the delay from the time of initiation of packet transmission at a sender to the time of initiation of packet reception at a receiver.
A reduced network wait time for data streams is important for various applications, such as algorithmic trading platforms. In an algorithmic trade, excessive and / or unpredictable delays in the execution of sales reduce the predictability of the algorithms and the potential for profit and, therefore, are a disadvantage compared to the competitors. It may be useful to measure the outbound network timeout and / or the roundtrip network timeout. In asymmetric networks with different network timeouts in each direction, forward network timeout measurements can facilitate the determination of network timeouts in each direction. Additionally, forward network timeout measurements can be useful in networks where transactions from host 674 to host 676 travel a different path than transactions from host 676 to host 674. For example, in an algorithmic trading, market data can be received through a broker system over a communications path from the exchange, and instructions can be sent to the exchange from the broker system over a path. other than communications.
Network device 602 can insert and remove timestamps on the fly in software and / or reconfigurable logic, without capturing the data packets, and without copying the data packets. In this way, insertion and removal of the timestamp can be carried out with a high degree of precision as potentially unpredictable delays associated with software processing and packet capture and / or copying are avoided. of data. The network device 602 can also measure the network timeout for each packet in the data stream, it can determine the network timeout per flow (such as an average of the network timeouts per packet for packets included in a data stream) and jitter (variation in network timeout), and may communicate to management station 604 the network timeout per flow and jitter.
FIG. 6 illustrates a logic block diagram of a system for managing network device 602, according to one embodiment of the invention. Network device 602 includes data path processing logic 682 for monitoring data flows 695, an output interface 696, and traffic analysis logic 694. The data path processing logic 682 is configured to provide information 686 related to the network data to the network data and traffic analysis logic 694 directly to the outbound interface 696 along the path 692 of the data. Information 686 related to network data may include, without limitation, data obtained from an application of one or more rules to network data, including data streams 695, statistics associated with network data, granularities time frames in which data and / or rule-based statistics and network timeout measurement information associated with network data are collected, as described above with reference to FIG. two. The network device 602 may be configured to identify a subset of the data streams 695, and to collect the information 686 related to the network data from the identified subset of the data streams 695. Traffic analysis logic 694 processes information 686 related to network data to obtain network traffic analysis data, as described with reference to FIGS. 2, 4-5, and 7-8. Traffic analysis logic 694 may be configured by another device based on address information associated with the other device. The other device may be the management station 604. Alternatively, the other device can be another network device that interfaces with a management station. The traffic analysis logic 694 may generate one or more packets that include the network traffic analysis data and address information.
In one embodiment, the traffic analysis logic 694 may generate network traffic analysis data 690 in packet form, and may provide the network traffic analysis data 690 to the outbound interface 696. Traffic analysis logic 694 is operable to send network traffic analysis data 690 to the other device (such as management station 604) regardless of a real-time request, from the other device, for at least a portion of the network traffic analysis data 690. The real-time request can be a poll from the other device. As described above with reference to FIG. 2, a transmission-based management, without request, can significantly reduce the network bandwidth overhead reduced with a network management eliminating the overhead due to probes in reception-based management protocols, without request, such as Simple Network Management Protocol (SNMP).
In this embodiment, the management based on the transmission, without request, can be carried out independently of the traditional network management protocols, since the traffic analysis logic 694 can increase the data flows 695 that travel the data path 692 with the network traffic analysis data 690. As described above with reference to FIG. 2, typical SNMP stacks may not be designed for increasingly fine-grained monitoring, and may not scale well, which may be necessary for monitoring packet streams. In addition, management station 604
ES 2 652 292 T3 can provide control information 688 to traffic analysis logic 694 by means of data path processing logic 682 without traversing a local management port 684. In the present embodiment, the local management port 684, if included in the network device 602, may support a portion configuration of the network device 602 other than the traffic analysis logic 694.
Traffic analysis logic 694 may be configured to send, without request, network traffic analysis data 690 to the other device based on a data transmission period. Traffic analysis logic 694 may be configured to collect information 686 related to network data based on a data collection period. The traffic analysis logic 694 may be configurable responsive to a subscription by the other device to the network traffic analysis data 690. The subscription may identify the data streams 695 based on identifiers, each of the identifiers being associated with a corresponding one of the data streams 695. The traffic analysis logic 694 may be configurable responsive to the other device to advertise the data streams 695 to the other device.
In another embodiment, the traffic analysis logic 694 may provide network traffic analysis data 691 to a local management port 684. Local management port 684 may provide network traffic analysis data 691 to management station 604. Management station 604 may provide control information 689 to traffic analysis logic 694 through local management port 684, which may be configured to support a configuration of traffic analysis logic 694.
FIG. 7 illustrates a logic block diagram of the traffic analysis logic 694 included in the network device 602 (see FIG. 6), in accordance with one embodiment of the invention. Traffic analysis logic 694 may include one or more data reduction logic 700, transmission logic 702, without request, alert generation logic 704, network timeout analysis logic 706, and network timeout logic 706. fluctuation, calculation logic 708 and control logic 710.
Data reduction logic 700 may be configured to perform traffic analysis logic 694 functions associated with data reduction. For example, the data reduction logic can be configured to process first data (such as first non-reduced statistical data that may include first non-reduced data of network performance) measured in time intervals of a first time granularity to obtain second data ( such as second reduced statistics data which may include second reduced network performance data) associated with time intervals of a second granularity of weather. The first time granularity can be finer than the second time granularity. Unreduced statistical data can be measured by at least one of a plurality of microcode controlled state machines (see below with reference to FIG. 8), and can be measured based on the network data included in each. of a plurality of data streams 695 traversing the at least one of the plurality of microcode controlled state machines. The volume of the reduced statistical data can be reduced relative to the volume of the non-reduced statistical data, such as by at least ten times. Volume reduction can be based on the performance of a mathematical operation on the non-reduced statistical data, such as at least a minimum, a maximum, a mean, a convolution, a moving average, a sum of squares, a filter operation linear and a non-linear filtering operation. The data reduction logic 700 may be configurable to reduce a volume of the non-reduced statistical data to obtain the reduced statistical data, so that an indication of a function (characteristic) of the non-reduced statistical data is maintained in the statistical data. reduced, the function being masked if the reduced statistical data were based on an aggregation of the non-reduced statistical data in each of the time intervals of the second time granularity. The reduced statistics data may have other attributes of the reduced network performance data 660 described with reference to FIGS. 4A through 4C.
The transmit logic 702, without prompting, may be configured to perform traffic analysis logic 694 functions associated with transmit-based management, without prompting, as described with reference to FIG. 6. For example, the transmission logic 702, without a request, may be configured to send the reduced statistical data on a network independent of a real-time request from the network. The transmission logic 702, without prompting, may be configurable to generate one or more packets that include reduced statistical data and address information associated with a device located elsewhere on the network. Transmission logic 702, without prompting, may be configurable to advertise the plurality of data streams to a device located elsewhere in the network. With reference to FIG. 6, the transmitting logic 702, without prompting, may be operable to send, without prompting, the reduced statistical data by communications that traverse at least a portion of the data path 692.
Alert generation logic 704 may be configured to perform functions of network device 602 (see FIG. 2) associated with generating alert indications, as described with reference to FIG. 2. Alert generation logic 704 may be configured to generate an alert indication associated with at least one of the plurality of data streams 695 (see FIG. 8) processing statistical data to determine whether the statistical data implies a characteristic associated with the alert. The feature can
ES 2 652 292 T3 take various forms known to a person with a normal level of skill in the art related to network data. For example, the characteristic can be indicated as a function of the appearance of a bit pattern in the network data and / or as a function of the appearance of a pattern of variation in a data transfer rate associated with the network data. . Alternatively or additionally, the feature may take various forms known to one of ordinary skill in the art related to the operability of network devices. For example, the operational characteristic may be indicated based on the existence of an alarm condition of a particular degree of severity, or it may be based on configuration information, such as hardware, software, and / or service configuration. to the client. Statistical data may be measured by at least one of a plurality of microcode controlled state machines (see below with reference to FIG. 8), and can be measured as a function of the network data included in each of a plurality of data streams 695 traversing the at least one of the plurality of microcode controlled state machines.
In one embodiment, the alert generation logic 704 may be configured to determine whether the statistical data involves the characteristic associated with the alert based on the performance of a mathematical operation on the statistical data. The mathematical operation can include at least one of a minimum, a maximum, a mean, a convolution, a moving average, a sum of squares, a linear filter operation, and a non-linear filter operation. The alert generation logic 704 may be configured to apply the mathematical operation to the statistical data in multiple time intervals, so that the characteristic associated with the alert is implied if the maximum of the statistical data in at least one of the plurality of time intervals is substantially greater than an average value of the statistical data in the at least one of the multiple time intervals.
The jitter and network timeout analysis logic 706 may be configured to perform analysis on the measured network timeout data per packet to obtain network timeout information per flow. and fluctuation. For example, jitter and network timeout analysis logic 706 may perform a mathematical operation on per packet network timeout data to obtain per flow network timeout information. and fluctuation. The math operation can include at least one of a minimum, a maximum, a mean, a convolution, a moving average, a sum of squares, a linear filter operation, and a non-linear filter operation.
Calculation logic 708 may be configured to perform mathematical operations to support data reduction logic 700, alert generation logic 704, and jitter and network timeout analysis logic 706. The mathematical operation can include at least one of a minimum, a maximum, a mean, a convolution, a moving average, a sum of squares, a linear filter operation, and a non-linear filter operation.
Control logic 710 may be configured to process control information received from the network (such as a management station 604; see FIG. 6) and to convert the control information into signals to configure one or more of the data reduction logic 700, of the transmission logic 702, without request, of the alert generation logic 704, of the 706 logic network timeout and jitter analysis and calculation logic 708.
FIG.8 illustrates a logic block diagram of the architecture of one embodiment of the invention. This architecture can be used in network device 602 (see FIGURES 2 and 6). Network device 602 can be deployed as a "stop in the thread" with three (or more) interfaces. In one embodiment, there is one interface for inbound network traffic 695, a second interface for outbound network traffic 697, and a third interface 1212 for outbound network traffic that has been duplicated or redirected, or for management communications. Packets 695 input from network 110 first enter a distribution circuit 1202. In the illustrated embodiment, the distribution circuit 1202 divides the input packets 695 into traffic segments. In another embodiment, the input packets 695 are divided into segments by a preprocessor that can precede the distribution circuit. This preprocessor, which can be a standard or custom protocol core, can also provide packet fragmentation / reassembly and / or reordering functionality. Typically, a traffic segment is a fixed-length byte sequence derived from a single input packet, in the same order as the bytes that entered distribution circuit 1202. A traffic segment should not be confused with a Transmission Control Protocol (TCP) segment, which could include multiple packets. If a packet does not have enough remaining bytes to fill a traffic segment, the remaining bytes of the traffic segment are left unused. Each byte of a traffic segment can be associated with a control bit that serves as a validity indicator, with unused bytes being marked as invalid.
In the embodiment illustrated in FIG. 8, each traffic segment is routed in parallel for processing by each rule engine of a set of rule engines 1204A - 1204N, hereinafter referred to as 1204. Distribution circuit 1202 also it holds each of the packets 695 input until an outbound interface 696 indicates to the distribution circuit 1202 whether the packet should be forwarded or deleted, eg by skipping it. These segments have a width in bytes identical to the width of the
ES 2 652 292 T3 bus for segments between distribution circuit 1202 and each rule engine 1204, and between distribution circuit 1202 and output interface 696.
Each rules engine 1204 asserts a forward indication to distribution circuit 1202 when it is ready for additional segments of traffic from distribution circuit 1202. When all rule engines 1204 have asserted their lines of advance, distribution circuit 1202 sends the next segment of traffic to all rule engines 1204. Each of the individual rule engines 1204 executes a configured rule. In one embodiment, each rule engine 1204 evaluates to a value of true or false and asserts a line executed at the end of each packet.
After a rule engine 1204 has completed the evaluation of a rule, it notifies the aggregation circuit 1206 of the result. If the rule evaluates to true, the line adapted to aggregation circuit 1206 is asserted. When the evaluation of a rule is completed for a piece of data, which may be the set of traffic segments obtained from the division of one or more packets 695 entered, the executed line is asserted. The action lines tell the aggregation circuit 1206 whether to redirect or duplicate the data segment, and allow future scaling to additional interfaces for duplication or redirection. When the output of a rule engine 1204A is to override the outputs of a subset of rule engines 1204B - 1204N, the rule engine 1204A may assert override lines corresponding to that subset of rule engines 1204B 1204N. In another embodiment, the rules engine 1204A may assert an override line that overrides the rules engines 1204B-1204N.
The aggregation circuit 1206 includes output logic that imposes norms, which are sets of rules and the logical, causal, and / or temporal relationship between them. The aggregation circuit 1206 waits until the rule engines 1204 assert their corresponding executed bits before making a decision based on the outputs of all the rule engines 1204. The decision, typically to drop, forward, or duplicate the packet, is passed to the outbound interface 696, along with the duplicate interface identifier. The mirroring interface identifier indicates to the outgoing interface 696 whether the packet is being mirrored. Aggregation circuit 1206 asserts a reset to distribution circuit 1202 when aggregation circuit 1206 determines that distribution circuit 1202 can skip all remaining segments of the current packet and go directly to processing the next packet. It may be desirable for the aggregation circuit 1206 to also support mirroring or redirection of traffic to the management interface 1212.
When a packet is to be forwarded, the outgoing interface 696 requests via the next packet line that the next packet be sent to it from the distribution circuit 1202. During the transfer of the next packet, the outgoing interface 696 asserts a next segment indication to the distribution circuit 1202 when it is ready for one or more additional segments of traffic from the distribution circuit 1202. In one embodiment, when outbound interface 696 receives traffic segments from distribution circuit 1202, outbound interface 696 may buffer part or all of the packet, outbound interface 696 may buffer part of the packet, or all of it, as required, before transmitting it as an outbound packet 697. This depends on the post-processing functions that may need to be carried out, which may include, without restriction, encoding. In another embodiment, segments of the packet may be sent as received by the egress interface 696. In that mode of operation, if the decision of the aggregation circuit 1206 is to drop the packet, then the packet is truncated and becomes practically unusable for the connected equipment receiving the packet.
For packet and stream processing, there is no need for any general purpose central processing unit (CPU) to be involved. A general / instruction / control management interface is available for external equipment, typically containing a CPU, to control distribution circuit 1202, aggregation circuit 1206, and all rule engines 1204 by controlling circuit 1206 aggregation.
One embodiment of a rule engine 1204 is a microcode controlled state machine that executes a configured rule based on behavior or signature. A rule is compiled to a set of bits, or microcode, which is used to program the microcode controlled state machine and associated configuration registers. Each microcode controlled state machine includes a calculation routine that operates according to the microcode stored in associated control storage. Microcode controlled state machines configure an optimized data path to carry out such operations as parity, masked parity, and scoping / include operations on each traffic segment. The data path comprises thin stages whose implementation requires only a few logic levels, thus allowing a very high frequency design.
The set of rule engines 1204 can be implemented as a chain processing fabric of microcode controlled state machines operating simultaneously and collaboratively on each traffic segment. This regular structure lends itself to creating high-capacity parallel designs by reiterating a small number of critical building blocks. It also provides an ability to preserve state information, such as TCP connection information, locally on the relevant microcode controlled state machine as part of its state. Unlike the typical approach in
ES 2 652 292 T3 state information firewall, which preserves all connections in a shared memory, this fabric also allows state information to be stored as a local state of a single microcode controlled state machine. However, the architecture also supports a global state table (which can contain connection information) that is available globally to all rule engines 1204. The global state table can be kept in a CAM or external memory, and can be implemented as memory on a chip. If it is on a CAM or external memory, the global status table can be accessed by the rules engines 1204 through the management interface 1212, which is responsible for a controller that maintains status information and presents information status relevant relevant to the current package to all rule engines. The rule engines 1204 can simultaneously access the information in the global state table, such as via hardware signal lines to each rule engine 1204. In the present embodiment, no clock cycles are wasted managing query request queues to a CAM or external memory. The global status table can be updated packet by packet by means of a dedicated hardware. This architecture, along with its associated set of instructions, can also be customized and optimized. This enables efficient, easily configurable and unified header processing and deep inspection of packet payloads.
Aggregation circuit 1206 includes policy-enforcing output logic. A rule can be a simple collection of rules related to the use of Boolean logic. In one embodiment, aggregation circuit 1206 aggregates the individual block outputs, for example expressed as a Boolean OR of multiple rules. If any of these multiple rules is a tree, each node in the tree can be configured to function as a logical OR or AND. A rule can be configured to be a complicated compound relationship between rules, such as a sum of products and / or a causal or temporal relationship. The aggregation logic can implement any combinatorial or sequential logic.
In one embodiment, the aggregation circuit 1206 generates control signals to activate and deactivate a subset of one or more of the set of rule engines 1204. The aggregation logic can also reset or provide rule feedback to subset of rule engines 1204, and can set parameters used by distribution circuit 1202. A rule engine 1204 may include logic and may generate control signals to directly turn one or more additional rule engines on and off.
Referring to FIGS. 6 and 8, the data path processing logic 682 may include the distribution circuit 1202, the one or more microcode controlled state machines 1204, and the aggregation circuit 1206. Data path 692 may include at least one distribution circuit 1202, output interface 696, and connections to distribution circuit 1202 and output interface 696 traversed by data packets included in one or more of the streams 695. of data traversing the network device 602.
FIG. 8 illustrates an example of a parametric architecture, allowing key performance metrics, such as throughput, to be scaled with design parameters, such as the width of the traffic segment, without changing the fundamental architecture structure. . Wider traffic segments, corresponding to a wider data path, can be used to increase the total throughput of the system by transmitting, without request, more bits per hardware clock cycle through the device. . It is possible to fine-tune the width of the data path and reach a trade-off between the use of silicon resources (gates) and the operating frequency of the apparatus. The worst throughput through the apparatus can be accurately calculated by multiplying the width of the traffic segment by the number of clock cycles per second divided by the worst number of clock cycles per traffic segment. For typical applications, the worst number of clock cycles per traffic segment is less than five, preferably two. The worst waiting time can be accurately calculated depending on whether the diversion policy is store and forward or toggle. For storing and forwarding, the worst wait time is directly proportional to the ratio of the number of segments in two packets of maximum size divided by the clock frequency. Processing time is linear in the number of traffic segments in a packet.
The architecture illustrated in FIG. 8 is designed to be optimal specifically for network monitoring, traffic analysis and security applications. However, this architecture is also general enough to implement general-purpose pattern matching, including on-the-fly database, deep inspection, and packet classification applications. The common denominator is the concept of data processing one segment at a time, the size of a segment being a design parameter of a parametric architecture.
The rules used by the rule engines 1204 can be specified in a number of ways, including without limitation hardware bit setting, use of a low-level assembler, translation of existing languages used by intrusion detection systems (IDS ) and common firewalls, or the use of high-level language. In one embodiment, a low-level assembler is used, based on a unique and proprietary Instruction Set Architecture (ISA) corresponding to an underlying hardware architecture optimized for network security applications. In another embodiment, a high-level language is used, with custom rule definition, based on a high-level proprietary language for the input section of
ES 2 652 292 T3 stream and packet inspection (SPIFE). Some examples of rules in a high-level rule-definition language include:
drop inbound eth: ip: tcp ip.src = 1.2.3.4, tcp.dport = 80;
Meaning: Drop incoming TCP packets (from the external network to the protected segment), which have a source IP address of 1.2.3.4 and a destination port 80 (http). drop inbound eth: ip: udp payload: "malicious";
Meaning: Drop incoming User Datagram Protocol (UDP) packets (from the external network to the protected segment) if their payload contains the keyword “malicious”. drop inbound eth: ip: udp payload: "mal * ious" [ignorecase];
Meaning: Drop incoming User Datagram Protocol (UDP) packets (from the external network to the protected segment) if their payload includes the keyword "malicious" in which any number of characters separates the "c" of the "i". The payload is not case sensitive, so, for example, “Malicious”, “mAliCious” and “MALICIOUS” are dropped.
count all inbound eth: ip: icmp icmp.type = PING_REPLY;
Meaning: Count Internet Control Message Protocol (ICMP) trace-response packets sent over the IP and Ethernet protocol layers. duplicate all inbound eth: ip: icmp icmp.type = PING_REPLY;
Meaning: Duplicate incoming ICMP trace-response packets sent over the Ethernet and IP protocol layers to the third interface without interfering with the normal flow of packets from the first interface to the second interface, or from the second interface to the first interface.
redirect all inbound eth: ip: icmp icmp.type = PING_REPLY;
Meaning: Redirect incoming ICMP trace-response packets sent over the IP and Ethernet protocol layers to the third interface.
FIG. 9 illustrates the use of the architecture of FIG. 8 for bi-directional applications, according to one embodiment of the invention. An example is client-server applications, for which it is desirable to monitor bidirectional protocol behaviors or triggering of events. If the server is outside the portion of the network protected by the appliance and the client is within that portion of the network, the traffic from the server is inbound and the requests and responses from that client are outbound. Incoming incoming packets 695 are processed by distribution circuit 1202, rule engine set 1204, and aggregation circuit 1206 to obtain outgoing incoming packets 697. The exit interface 696 is not shown in FIG. 9 for the sake of simplicity. Inbound outbound packets 1300 are processed by distribution circuit 1302, a set of rule engines 1304, and aggregation circuit 1306 to obtain outbound packets 1310. The distribution circuit 1202, the set of rule motors 1204 and the aggregation circuit 1206 form a first path in the first, or input direction, and can be aligned with the differentiated circuit 1302 of distribution, the set of rule engines 1304 and aggregation circuit 1306 that form a second path in a second, or outbound direction, other than, such as opposite, from the first direction. The alignment in this context is conceptual, and does not imply any restriction on the mutual physical positioning of these blocks in an implementation. To manage bi-directional applications, it may be desirable for rule engine set 1204 to exchange control information with rule engine set 1304. In another embodiment, each rule engine 1204 could dynamically alternate between processing traffic on the first run and the second run. This dynamic alteration can be controlled by microcode, and can also be controlled by the setting bits of the rule engine 1204. The rule engines 1204 can alternate between processing first tour and second tour traffic independently and / or as a group.
FIG. 10 illustrates an embodiment of the internal architecture of the distribution circuit 1202 shown in FIG. 8, according to an embodiment of the invention. Inbound packets 695 enter a frame buffer 1320. In the present embodiment, buffer 1320 is a FIFO buffer, and is logically organized into segment sizes equal to the width of the data path through the apparatus. The incoming packets 695 may have already been divided into traffic segments by means of a preprocessor, in which case frame buffer 1320 may not be required. Otherwise, the incoming packets 695 are placed in the frame buffer 1320 with a separator between the incoming packets 695. The frame buffer 1320 logically has a write port, for incoming packets, and two read ports, one for a distribution logic block 1324 and the other for the outgoing interface 696. A
ES 2 652 292 T3 standard implementation of such a buffer uses two separate blocks of memory, such that one is near the input interface and one is near the output interface. In a store-and-forward implementation, a packet remains stored in frame buffer 1320 until a decision from the rules engines 1204 has been communicated via aggregation circuit 1204 to outbound interface 696, causing the interface to Outbound 696 assert the next line of packets. In a switching implementation, each traffic segment of a packet is forwarded without delay to the egress interface 696. An abort signal may be sent to the outgoing interface 696 to cause the outgoing interface 696 to corrupt a portion of the packet to cause the packet to be discarded by devices at the receiving end in the network. Both the frame buffer 1320 and the distribution logic 1324 may have management / command / control interfaces.
Distribution logic 1324 pulls a data segment from frame buffer 1320 when all connected rule engines 1204 are ready for the next data segment, as indicated by their denial of their forward control lines to logic. 1324 distribution. If one or more of the rule engines 1204 is not ready, the dispatch logic 1324 denies the forward control line to the frame buffer 1320 and waits until all of the rule engines 1204 are ready. Distribution logic 1324 receives reset from aggregation circuit 1206, described with reference to FIG. 8, which causes dispatch logic 1324 to skip all remaining segments of the current packet and go directly to processing the next packet.
FIG. 11 illustrates the internal design of a rule engine 1204 based on a microcode controlled state machine configured in accordance with one embodiment of the invention. The design is based on a custom programmable state machine with independent local memory. Typically, the memory is Static Random Access Memory (SRAM), but it can be of a different type. State machine programming is accomplished by writing content to a control storage memory 1406. Bus implementations to allow reading from, and writing to, distributed local memory are well known in the art. It is also contemplated that the rules engine 1204 may be implemented in a variety of ways, such as using application specific integrated circuits (ASICs) or programmable logic devices (PLD).
Each rule engine 1204 may contain a small local first-in and out (FIFO) buffer 1400 to hold segments of traffic received from distribution circuit 1202 while each rule engine 1204 is processing a preceding segment. If present, this buffer indicates to distribution logic via the forward line when it can accept additional segments.
The purpose of the local buffer is to avoid periods of time during which no data is available to be processed by a rule engine 1204 (lags). The local buffer can be viewed as a fixed-length window that slides over the input data. A traffic segment is provided to each rule engine 1204 via distribution circuit 1202 when all rule engines 1204 have been asserted their lines of advance, indicating that the local buffers of all rule engines 1204 they have room for the traffic segment. The traffic segments already in the local buffers of the rule engines 1204 are available for parallel processing by all of the rule engines 1204. As a result, a rule engine 1204 that has completed processing a first traffic segment can immediately receive, without request, the next traffic segment from the local buffer, without being delayed by another rule engine 1204 that is still it has not completed the processing of the first segment. Since there is a maximum number of comparisons, and therefore of processing cycles, required to apply a rule to a traffic segment, the size of this local buffer can be limited. Typically, the processing of a traffic segment by means of a rule engine 1204 requires no more than two cycles. If two cycles are then set as the number of processing cycles for any traffic segment, sliding the window every two cycles the number of bytes required to include the next traffic segment ensures that none of the local buffers fill up.
A condition logic block 1402 indicates by a forward line when it is ready to receive the next data segment from input buffer 1400 or directly from distribution circuit 1202. Condition logic is configured by each microcode line to perform one or more comparisons on the current segment and, based on the comparisons, select the next state using a selector 1404. Condition logic 1402 and selector 1404 are included in a calculation routine 1403. Condition logic 1402 implements combinatorial operations just like sequential logic, which depends on its internal state. In the present embodiment, the next state is the address of the next microcode instruction to be executed. In addition, condition logic 1402 sets the execute, match, action, and invalidate indications provided to aggregation circuit 1206. The aggregation logic may generate control signals to turn the condition logic 1402 on and off, or to provide rule feedback to the condition logic 1402.
Each microcode line in control storage 1406 determines what type of comparison to perform on the current segment of traffic. Based on the results of the comparison, the microcode line also
ES 2 652 292 T3 provides the address of the next microcode line to be executed. In one embodiment, each line in control storage 1406 includes four types of information:
1. Control bits (such as opcodes or setup bits) that determine what kind of comparisons the condition logic 1402 performs, and what internal state should be stored in internal state variables (flops and registers).
two. Values used for comparisons. Comparison types include parity, set membership, scope comparison, and more complex operations, such as counter comparisons that indicate whether a bit sequence has occurred more than 3 times in the previous 10 segments.
3. Subsequent address addresses to be executed based on the output of condition logic 1402. Depending on the result of condition logic 1402, one of multiple following addresses may be selected. Allowing more than one next address allows greater flexibility to implement complex conditions, as long as there are clock cycles.
Four. Control of the internal state and primary outputs of the rule engine 1204. For example, this may include whether or not the executed line is asserted, either to advance the next segment in the packet or to hold for another comparison involving the current segment, or whether to move immediately to the edge of the current packet.
These various types of comparisons, along with the architecture, allow processing of both individual packets and packet streams by means of the set of rule engines 1204. A rule engine 1204 can process a stream without actually completely rebuilding it in the external memory of the system. Based on the microcode instructions, the rules engine 1204 can make decisions that are based on a sequence of events that occur over time and that are encapsulated in different packets.
FIG. 12 shows an example of a microcode instruction execution sequence to implement a comparison rule, according to an embodiment of the invention. The search sequence for a four-byte sequence “abcd” in two successive segments (each assumed to be 2 bytes), followed by a two-byte sequence with a value between “10” and “14”, inclusive . For a twenty-byte packet that is symbolically represented as “1234yzwxabcd12345678”, the actual state transitions from the start of the packet until a decision is 0 -> 1 -> 1 -> 1 -> 1 -> 1 -> 2 -> 3 -> 4. When the rule engine 1204 reaches state 4, it asserts both the executed and match outputs to the aggregation circuit 1206 in FIG. 8. If the data packets do not include the desired content, then as soon as the SEGMENT equals the two-byte packet separator "- -", there is an automatic transition to state 5. At state 5, the rules engine 1204 asserts the line executed and negates the adapted line.
The number of operations that can be executed in parallel in the SEGMENT and their type depends on the specific hardware implementation, including the width of the control storage memory line. This example assumes that comparing the SEGMENT with a given value and checking whether the SEGMENT is within a given scope can be done in parallel. Otherwise, operations can be performed in two separate consecutive clock cycles. For example, state 3 performs two checks in parallel and assumes that the next three address values can be specified in a memory line of control storage.
FIG. 13 illustrates an example of the implementation of the condition logic of FIG. 11, according to an embodiment of the invention. Based on the segment entered from local buffer 1400 and the opcode and configuration bits from control storage 1406, a set of parallel comparisons can be made between the segment, operands, and internal variables of the condition. An operand is a configured value used for a comparison. An internal state variable includes values stored in flops, registers, or counters, such as statistics. These values include the result of comparisons between stored values, such as the number of times the value in a first counter has exceeded the value in a second counter. In the present embodiment, each condition logic block 1402 has two counters that are dedicated to counting the number of packets and the total number of segments (or bytes) that have been processed by the microcode in control storage 1406. There are also counters and status registers associated with input, output, and management interfaces. Comparisons can be made between registers and local counters and / or global counters.
Each sub-block in FIG. 13 implements a specific comparison. Operand comparisons with data such as a parity check 1502 and span 1504 are implemented by means of condition check circuits 1500, which are used to evaluate signature-based rules. Modification of the internal state stored in flops, registers or counters 1510 and comparisons between a variable internal state and an operand 1512 (or another internal state register / variable or a global state variable / counter) are implemented by means of analysis circuitry 508 the condition, which can be used to evaluate behavior rules or to collect statistics. There is an automatic update of the internal states, such as the number of
ES 2 652 292 T3 bytes of the current packet that have been processed until then, as specified by the opcode and configuration inputs. The results of the parallel comparisons between subblocks are augmented by one block in a configurable block 1514 of output logic (Boolean or sequential or both). The next address selection used by selector 1404 and the outputs of the microcode controlled state machines visible to aggregation circuit 1206 are configured by configurable output logic 1514.
Embodiments of the present invention allow modification of network traffic that can have bitwise granularity (be granular down to the bit) anywhere in the network traffic. Network traffic can be modified in packet form anywhere in the payload or in the packet header. These modifications to the payload or packet header can include changes to one or more existing bits, the insertion of one or more bits, and the removal of one or more bits. It is also contemplated that the embodiments of the present invention allow a selective reflection of the incoming traffic with a bit-by-bit granularity, so that only the traffic that needs to be looked at in detail is directed to an entity with a lower processing transfer speed. packet, such as a CPU or a protocol analyzer.
With reference to FIG. 8, the architecture of an embodiment of the invention also supports granular traffic shaping and reflection. After completing the evaluation of a rule for a data segment corresponding to one or more input packets 695, each rule engine 1204 notifies the aggregation circuit 1206 via instruction lines of modifications to be made to each packet in the data segment. Modification instructions indicated by a rule motor 1204A may be identical to, or overlap, the modification instructions indicated by one or more of the other rule motors 1204B 1204N. The logic in the aggregation circuit 1206 which may include both sequential and combinatorial logic combines the modification instructions indicated by the rule engines 1204 into a modification command that includes indications of all the modifications that are to be made to each packet in the data segment. When the modification instructions indicated by the rule engines 1204 are combined in the modification order, the aggregation circuit 1206 may delete or modify modification instructions to eliminate redundancy.
For each packet in the data segment, outbound interface 696 typically responds to a modify command from aggregation circuit 1206 if outbound interface 696 has received indications from aggregation circuit 1206 on the decision line that the packet be forwarded, redirected or duplicated. Since the outgoing circuit 696 receives traffic segments from the distribution circuit 1202 in response to the next packet and next segment indications, the outgoing circuit 696 may buffer part or all of a packet to facilitate packet modification via output circuit 696. The output circuit 696 may contain memory that stores the modify command or a processed version of the modify command. As part of modifying the packet, the output circuit 696 may modify fields in the packet used for error detection or error correction, such as the Frame Check Sequence (FCS) or Cyclic Check Sequence field. redundancy (CRC) for the header, payload, or the entire packet. If the output circuit 696 inserts fields into a packet or encapsulates a packet with a new header, one or more new fields may be added to the packet for error detection or error correction.
Based on the outputs of the rule engines 1204, the aggregation circuit 1206 uses the identifier lines from the mirroring interface to indicate to the outgoing interface 696 that a packet is being redirected or duplicated, and the interface (s) to which it is the package is being shipped. The redirected or duplicated packet can be modified by the outgoing interface 696. The mirrored data can correspond to one or more ports 800 which can be any combination of physical and logical ports. The reflected data may be data redirected to management interface 1212 from outbound interface 696 or duplicate data directed to management interface 1212 and also forwarded from outbound interface 696. Some combination of the egress interface 696 and the management interface 1212 may have a limited amount of memory for mapping the data transfer rates of the traffic segments entering the management interface 1212 from the distribution circuit 1202 to the output of the management interface 1212. Any data transfer rate matching can also be accomplished by external devices connected to the management interface 1212. The output of the management interface 1212 may combine reflected data and management or control communications.
Packet modifications can facilitate network monitoring and security, such as allowing selective monitoring of suspicious traffic, preventing attacks, or mitigating ongoing attacks. For example, the input packets 695 in FIG. 8 with a non-standard or unassigned number of TCP ports, using the architecture shown in FIG. 8, forming outbound packets 697 with a number of TCP ports mapped to a downstream secure application for monitoring. Incoming packets 695 from unknown sources with rogue Internet Protocol (IP) options can be modified by creating outgoing packets 697, for example, with the IP options cleared or modified to be inoperative to prevent or mitigate attacks. Inbound packets 695 with spoofed IP addresses can be modified into outbound packets 697 with the IP address of a downstream monitoring device.
ES 2 652 292 T3
This modification can also facilitate traffic management in addition to, or independently of, facilitating network security. For example, 695 inbound packets can be modified by creating 697 outbound packets with an embedded virtual local area network (VLAn) tag or with a tag-based multiprotocol switching (MPLS) tag that can correspond to the forwarding, for part of the client, of incoming 695 packets to a specific LAN segment in the case of the VLAN tag, or with a specific MPLS tunnel in the case of the MPLS tag. This is an example of package labeling. Incoming packets 695 can also be modified into outgoing packets 697 with a label-based multiprotocol switching (MPLS) label that contains a quality of service mark indicating the type of processing that this packet should receive from downstream devices. . This operation is an example of packet coloring.
This modification can also facilitate the integration of devices into a system. For example, the incoming packets 695 can be modified into outgoing packets 697 having an encapsulated header. This encapsulated header can convey meaning control information for a particular downstream device. A common purpose of header encapsulation is to indicate the results of preprocessing of incoming packets 695 by a device with the architecture shown in FIG. 8, so that downstream devices, such as NP, receiving outbound packets 697 do not need to repeat the same processing, saving computational resources and improving network performance.
Reflection is used to direct incoming traffic to an entity such as a CPU or protocol analyzer for detailed traffic monitoring and analysis. Selective reflection between input ports 800 is desirable because a CPU or protocol analyzer typically cannot process packets at the same data transfer rate as the architecture of FIG. 8, which is designed for high data transfer rates of multiple gigabits per second.
Reflection with bitwise granularity allows selective, precise, surgical reflection. Using the architecture shown in FIG. 8 to flexibly filter high-speed traffic allows the use of a CPU or protocol analyzer for precisely directed traffic sent over the management interface 1212. There is also no restriction on the types of ports 800, such as a physical port or a logical port defined by a virtual LAN, that can be mirrored to the management interface 1212. For example, it may be desirable to inspect only packages that report stock quotes or a particular Web page. Deep packet inspection supported by the architecture of FIG. 8 allows the application of rules, including signature-based rules, in which the signature can appear in the header or payload of individual packets, or in a sequence of packets. Behavior rules can also be integrated with signature-based rules to define the criteria for selective reflection. High-speed traffic filtering using a combination of signature-based and behavioral rules can be tailored to produce a system-level solution that better leverages the processing capabilities of the CPU or protocol analyzer, without requiring NP or CAM expensive. For example, the architecture of FIG. 8 can apply an inclusive signature-based rule for reflected traffic if the reflected traffic load is substantially less than the maximum throughput of the protocol analyzer, and can apply progressively stricter signature-based rules as the reflected traffic load approaches at the maximum throughput of the protocol analyzer.
The architecture of FIG. 8 is hardware-based and optimized for header analysis, deep packet inspection, and packet modification applications. In particular, the architecture does not incorporate general-purpose component designs such as CPUs. To avoid intrusive redesign of NP and switch low-level hardware, registries, and software, an easy way to incorporate this architecture into existing serial components is to integrate the architecture into a component in the Physical Layer (PHY) or in a combination of the PHY and the media access control (MAC) sublayer of the seven-layer Open Systems Interconnection (OSI) reference model for network protocol layers. These layers, moving up from untreated bits in a communication channel to application protocols commonly used by end users, include the physical layer, the data link layer, the network layer, the transport layer, the session, presentation layer, and application layer. The division of the layers of the OSI reference model is based on principles that include a clear definition of the functions carried out by each layer, an abstraction of layers to minimize dependencies between layers and a facilitation of the definition of standards.
With reference to FIG. 8, the architecture of an embodiment of the invention also supports data reduction, transmission-based management, no request, alert generation, and network timeout and jitter analysis. As described with reference to FIG. 7, these functions are supported by logic included in the traffic analysis logic 694. In one embodiment, the traffic analysis logic 694 includes dedicated hardware logic to perform each of these functions. Traffic analysis logic 694 can be included, along with the rest of the architecture shown in FIG. 8, on a single chip. The single chip can be a system-on-chip, and it can include one or more integrated circuits. The traffic analysis logic 694, along with the rest of the architecture shown in FIG. 8, can be implemented in hardware circuitry and / or reconfigurable logic. Alternatively, the traffic analysis logic 694 may be implemented in firmware.
ES 2 652 292 T3
Traffic analysis logic 694 may be configured to receive information related to network data (such as information 686 related to network data described with reference to FIG. 6) and flow identification information from microcode controlled state machines 1204. With reference to FIG. 7, one or more of the data reduction logic 700, the transmission logic 702, without request, the alert generation logic 704, the network delay time and jitter analysis logic 706, calculation logic 708 and control logic 710 are configured to process information related to network data and flow identification information as part of the performance of their functions. Additionally, traffic analysis logic 694 may be configured to receive control information (such as control information 688 described with reference to FIG. 6) from distribution circuit 1202. With reference to FIG. 7, the control logic 710 may be configured to process the control information, and to convert the control information into signals to configure one or more of the data reduction logic 700, the transmit logic 702, without prompting. , alert generation logic 704, network timeout and jitter analysis logic 706, and calculation logic 708. In one embodiment, packets are provided that include network traffic analysis data generated by transmission logic 702, without prompting (such as the network traffic analysis data 690 described with reference to FIG. 6 ) to the outgoing interface 696 in response to the next packet signal from the outgoing interface 696.
In one embodiment, the microcode controlled state machines 1204 may be responsively configurable to the control information to vary a granularity of time in which the non-reduced statistical data is collected. The control information may be provided to the microcode controlled state machines 1204 by means of the distribution circuit 1202 in a manner similar to how segments of the input packets 695 are provided to the microcode controlled state machines 1204.
The packet modifications, as described above with reference to FIG. 8, can also facilitate network timeout measurement, in addition to or independently of facilitating network security and traffic management. For example, incoming packets 695 included in one or more data streams (such as logical ports 800) can be modified into outgoing packets 697 with an inserted time stamp. The time stamp can indicate a transmission time. The content of the timestamp can be determined based on a time reference signal provided by a time source coupled with the microcode controlled state machines 1204. The timestamp may be provided as part of the modify instruction to aggregation circuit 1206.
With reference to FIG. 11, condition logic 1402 may be configured by microcode stored in control storage 1406 to evaluate a rule for measuring per packet network timeout associated with incoming packets 695 included in one or more data streams ( such as logical ports 800).
With reference to FIG. 8, each rule engine 1204 may interface with an associated addressing module. FIG. 14 illustrates a logic block diagram of the interface between rule engines 1204 and their associated addressing modules 2400, in accordance with one embodiment of the invention. Each rule engine 1204 can apply a rule to extract one or more fields from a network data entry unit, such as an input packet. The rule can have bitwise granularity in the packet header and payload, so that the extracted fields can have bitwise granularity and be from any portion of the packet. Each rule engine 1204 provides the extracted fields to an addressing module 2400. In one embodiment, each rule engine 1204 may provide a metered network wait time per packet to the addressing module 2400. Each addressing module 2400 processes the data to generate an addressing identifier that is desirably smaller in bit width than the extracted fields provided to addressing module 2400, and provides the addressing identifier back to the rule engine 1204 that provided the fields. extracted. The addressing identifier can be associated with a packet type or packet stream or, more generally, with any subset of data units on the network that share a property or attribute. Each 2400 addressing module can be configured through the 1212 management interface. In one embodiment, the addressing identifiers may be provided to the management interface 1212.
Alternatively, each rule engine 1204 may generate the addressing identifier as part of its network data entry unit processing. In this case, the function of the addressing modules 2400 is performed by the rule engines 1204, rendering separate addressing modules 2400 unnecessary.
In one embodiment, each rule engine 1204 may apply a rule to produce modification instructions based on categorization information, such as the addressing identifier. Modify instructions can include the addressing identifier. The aggregation circuit 1206 may combine the modification instructions indicated by the rule engines 1204 into a modification command that is provided to the output circuit 696, as described above. Depending on the change command, the output circuit 696 may add the addressing identifier to the network data unit. The
ES 2 652 292 T3 addressing identifier can be added to any part of the network data unit, such as the headend. Based on the routing decision of the aggregation circuit 1206, the output circuit 696 may provide the modified unit of network data to a management system via the management interface 1212. The output circuit 696 may also transmit the modified unit of network data to downstream devices. A benefit of attaching categorization information, such as a addressing identifier, to a unit of network data passed to other devices on the network is so that downstream devices can take advantage of the traffic processing and analysis capabilities of the network. network of an upstream device. The downstream devices may not have the same traffic processing and analysis capabilities as the upstream device. Downstream devices can also take advantage of the categorization information associated with a unit received from network data to simplify and streamline the analysis and processing of network traffic carried out on downstream devices.
Embodiments of the invention are cost effective, simple to use, manageable, and flexible. With a unified block design and algorithm in distribution circuit 1202, rule engines 1204, and aggregation circuit 1206, the apparatus performs header analysis, deep packet inspection, and packet modification functions. without the use of multiple expensive coprocessors, such as NP, for header processing and packet modification and a CAM for pattern matching. The apparatus can be deployed incrementally to balance risk with available budget. The apparatus can be integrated as part of, and as part of, a physical layer, data link layer, or other lower-layer interface to enable higher-layer rule-based processing in cost-effective low-power devices that do not use none of the NP and CAM calculation resources. The architecture of the apparatus is adapted to headend analysis, deep packet inspection and packet modification at multi Gb / s and higher input speeds. The apparatus provides an interface 1212 for network monitoring and management, configuration of its specialized features, and mirrored data output, and can also support the use of preprocessors and postprocessors for specific customer needs.
Embodiments of the invention also have predictable and easily verifiable performance, based on their architecture. Implementing the set of rules engines 1204 as a chain processing fabric of microcode state machines operating simultaneously and collaboratively ensures that the most unfavorable process throughput and wait time can be calculated and constrained across the apparatus. As a result, accurate predictions can be made about when the apparatus can be operated at wire speed. The wire speed operation is fast enough to process, without inadvertent loss of traffic, the worst combination of incoming packet size and packet transfer speed in packets per second given a rule of maximum complexity. Furthermore, since there is a more unfavorable deterministic number of clock cycles for the processing of any traffic segment by means of a rules engine 1204, the apparatus may have a small limited processing delay between mixtures of traffic types, sizes of packets and complexity of the rules. A small narrow delay means that the apparatus can use simple on-chip buffers instead of external memory or caches which may require a memory hierarchy or complex queuing structures. The use of simple on-chip buffers not only increases the performance of the apparatus through efficient and optimal use of hardware resources, such as gates and memory elements, but also avoids bias cases related to various traffic patterns. It also enables validation using formal verification and structural coverage, which reduce the likelihood of leaks and design errors.
One of ordinary skill in the art will understand that the embodiments described herein can process various forms of network traffic including, without limitation, packets. For example, the embodiments described herein can process cells or frames.
Embodiments of the invention may allow network monitoring that may be comprehensive enough to identify network phenomena that may not be identifiable by previous network monitoring and management systems, such as microbursts or new types of non-viral attacks. recognized by firewalls or AV software. Effective monitoring requires extensive collection of network statistics to allow analysis of network behavior. The statistics collection can be complemented by a snapshot copy of all the statistics collected in a flash, or the aggregation and correlation of information from multiple devices to provide a clear view of the status and behavior of the network.
The foregoing description, for the purpose of explanation, has used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that no specific details are required to practice the invention. Therefore, the foregoing descriptions of specific embodiments of the invention are presented for illustrative and descriptive purposes. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed; Obviously, many modifications and variations are possible in view of the above teachings. The embodiments have been chosen and described to best explain the principles of the invention and its practical applications, therefore allowing others skilled in the art to optimally utilize the invention and various embodiments with various
ES 2 652 292 T3 modifications are also suitable for the particular use envisaged. The following claims and their equivalents are intended to define the scope of the invention.
Contents5
58 members in 8 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 201261734909 | United States of America | P | |
| 201261734909P | United States of America | – | |
| 201261734910 | United States of America | P | |
| 201261734910P | United States of America | – | |
| 201261734912 | United States of America | P | |
| 201261734912P | United States of America | – | |
| 201261734915 | United States of America | P | |
| 201261734915P | United States of America | – | |
| 2013073679 | United States of America | W |
Members58
| Document | Office | Kind | |
|---|---|---|---|
| CA2619772A1 | Canada | A1 | |
| WO2007024647A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2007056028A1 | United States of America | A1 | |
| US2007056029A1 | United States of America | A1 | |
| US2007056030A1 | United States of America | A1 | |
| US2007058540A1 | United States of America | A1 | |
| WO2007024647A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2008005858A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2008005864A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2008005866A2 | World Intellectual Property Organization (WIPO) | A2 | |
| EP1915671A2 | European Patent Office (EPO) | A2 | |
| WO2008005864A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2008005858A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2008005866A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US2010008359A1 | United States of America | A1 | |
| US2010011101A1 | United States of America | A1 | |
| US2010011434A1 | United States of America | A1 | |
| WO2011006117A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US7882554B2 | United States of America | B2 | |
| US7890991B2 | United States of America | B2 | |
| WO2011006117A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US7937756B2 | United States of America | B2 | |
| US8024799B2 | United States of America | B2 | |
| EP2452466A2 | European Patent Office (EPO) | A2 | |
| US8296846B2 | United States of America | B2 | |
| JP2012533231A | Japan | A | |
| US8346918B2 | United States of America | B2 | |
| US8665868B2 | United States of America | B2 | |
| US2014164609A1 | United States of America | A1 | |
| WO2014089489A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2014169196A1 | United States of America | A1 | |
| US2014172852A1 | United States of America | A1 | |
| US2014173102A1 | United States of America | A1 | |
| WO2014089489A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1915671A4 | European Patent Office (EPO) | A4 | |
| JP5661764B2 | Japan | B2 | |
| WO2015105681A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2015105684A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2015236895A1 | United States of America | A1 | |
| US2015244594A1 | United States of America | A1 | |
| CA2619772C | Canada | C | |
| EP2929472A2 | European Patent Office (EPO) | A2 | |
| EP2929472A4 | European Patent Office (EPO) | A4 | |
| US9407518B2 | United States of America | B2 | |
| EP2452466A4 | European Patent Office (EPO) | A4 | |
| HK1215479A1 | Hong Kong, China | A1 | |
| EP3092737A1 | European Patent Office (EPO) | A1 | |
| EP3092771A1 | European Patent Office (EPO) | A1 | |
| EP3092771A4 | European Patent Office (EPO) | A4 | |
| EP3092737A4 | European Patent Office (EPO) | A4 | |
| EP2929472B1 | European Patent Office (EPO) | B1 | |
| US9787556B2 | United States of America | B2 | |
| DK2929472T3 | Denmark | T3 | |
| ES2652292T3This record | Spain | T3 | |
| US10069704B2 | United States of America | B2 | |
| EP3092737B1 | European Patent Office (EPO) | B1 | |
| EP1915671B1 | European Patent Office (EPO) | B1 | |
| EP2452466B1 | European Patent Office (EPO) | B1 |
Numbers
- Publication
- 2652292
- Application
- 13860780
Titles2
- Spanish
- Aparato, sistema y procedimiento para la monitorización de red mejorada, comunicación de datos, y proceso de datos
- English
- Apparatus, system and procedure for enhanced network monitoring, data communication, and data processing
Classification
- CPC, 7
- H04L43/04
- G06F16/904
- H04L41/142
- H04L43/026
- H04L43/0858
- H04L43/087
- H04L43/106
- IPC, 1
- H04L12 24