Distributed ipfix data stream processing method, device and electronic equipment

Abstract

The application provides a distributed IPFIX data flow processing method, device and electronic equipment. IPFIX functions are dispersed into multiple matrix units through a matrix distributed architecture, so that load balancing of flow table storage is achieved. A first table item storage address is determined through hash calculation, and local or remote storage is performed based on the address attribution, so that centralized access bottlenecks of a single storage unit are avoided. A local cache aggregation mechanism is introduced at the same time, flow requests to the same destination unit are aggregated, and the aggregated table item information is sent at one time when the number of statistics reaches a threshold value. When the threshold value is not reached within the aging time, the table item information in the cache is sent and the corresponding cache table item is deleted. In this way, the number of transmissions between matrix units is reduced, source hotspot congestion is alleviated, bandwidth occupation is reduced, and IPFIX concurrent processing speed and memory utilization are improved.

Description

Technical Field

[0001] This application relates to the field of network traffic analysis, and in particular to a distributed IPFIX data stream processing method, apparatus, and electronic device. Background Technology

[0002] IPFIX (IP Flow Information Export) is a network technology for data flow analysis, typically implemented through a combination of chip hardware and software. The hardware is responsible for aggregating, statistically analyzing, and reporting flow information, while the software handles upper-layer monitoring, traffic statistics, and network attack detection. In IPFIX hardware implementations, storage and statistical analysis based on packet 5-tuples or even 7-tuples are required, resulting in significant memory resource consumption and representing one of the industry's major pain points.

[0003] Existing technologies primarily reduce memory usage through two approaches: one is to employ two-level flow tables, using ACLs (Access Control Lists) to filter out irrelevant traffic before it enters the IPFIX module for storage and statistics; the other is to set a sampling window, using random numbers to control the sampling frequency to reduce the amount of data. Both approaches are implemented at the single-chip or single-board level, with the core idea being to reduce memory and bandwidth pressure by decreasing the amount of data.

[0004] However, existing technologies mainly focus on IPFIX implementation at the single-chip or single-board level, without addressing matrix distributed architecture. When multiple ports and multiple matrix units work simultaneously, flow table access tends to concentrate in a single storage unit, causing hotspot access issues. At the same time, reducing memory usage through sampling or filtering sacrifices the completeness and accuracy of traffic statistics, failing to meet the needs of full traffic monitoring for critical ports. Furthermore, existing technologies do not address the dynamic reuse of IPFIX entry space and packet forwarding entry space. The fixed allocation of IPFIX entry space cannot flexibly adapt to actual traffic demands, resulting in low memory resource utilization efficiency. Summary of the Invention

[0005] This application provides a distributed IPFIX data stream processing method, apparatus, and electronic device to improve processing efficiency and memory resource utilization in multi-port concurrent scenarios.

[0006] In a first aspect, embodiments of this application provide a distributed IPFIX data stream processing method. The method is applied to a forwarding device, which is deployed with IPFIX matrix units distributed in a matrix pattern. The method includes: Receive message streams through the local IPFIX matrix unit; Based on the first hash calculation parameters, the flow identifier information of the message flow is hashed to determine the storage address of the first table entry; The matrix cell to which the first entry belongs is determined based on its storage address. When the storage address of the first entry belongs to the local IPFIX matrix unit, the entry is stored and counted in the local IPFIX matrix unit. When the storage address of the first entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows direct transmission, the flow request is transmitted to the destination IPFIX matrix unit corresponding to the storage address of the first entry for entry storage and statistics. When the storage address of the first entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows caching, the local IPFIX matrix unit aggregates and counts the flow requests flowing to the destination IPFIX matrix unit through caching. When the number of counts reaches a threshold, the aggregated entry information is sent to the destination IPFIX matrix unit.

[0007] Secondly, embodiments of this application provide a distributed IPFIX data stream processing device deployed in a forwarding device. The device comprises IPFIX matrix units arranged in a matrix distribution. Each IPFIX matrix unit includes a stream request initiation module, a NOC routing module, and an entry storage module. The device includes: The flow request initiation module is used to receive a packet flow, perform a hash calculation on the packet flow based on a first hash calculation parameter, determine the storage address of a first table entry, and determine the matrix unit to which the first table entry belongs based on the storage address of the first table entry. When the storage address of the first table entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows caching, the flow request initiation module is also used to aggregate and count the flow requests flowing to the destination IPFIX matrix unit through caching. The NOC routing module is configured to transmit the flow request to the destination IPFIX matrix unit corresponding to the first entry storage address when the first entry storage address belongs to another IPFIX matrix unit and the other IPFIX matrix unit allows direct transmission; when the statistical quantity reaches a threshold, the NOC routing module is also configured to send the aggregated entry information to the destination IPFIX matrix unit. The table entry storage module is used to store and count entries in the local IPFIX matrix unit when the first table entry storage address belongs to the local IPFIX matrix unit; and to store and count entries in the table entry storage module of the destination IPFIX matrix unit when the first table entry storage address belongs to another IPFIX matrix unit.

[0008] Thirdly, embodiments of this application provide an electronic device, the electronic device including a memory for storing one or more programs; when the one or more programs are executed by the processor, the methods in the first aspect and various possible implementations described above are implemented.

[0009] The technical solutions provided in the embodiments of this specification may include the following beneficial effects: Compared to existing technologies, the IPFIX data stream processing method, apparatus, and electronic device provided in this application, based on a distributed implementation, distributes the IPFIX function across multiple matrix units through a matrix distributed architecture, achieving load balancing for flow table storage. The storage address of the first entry is determined through hash calculation, and storage is performed locally or remotely based on address attribution, avoiding the bottleneck of centralized access from a single storage unit. Simultaneously, a local cache aggregation mechanism is introduced to aggregate flow requests destined for the same unit. When the number of requests reaches a threshold, the aggregated entry information is sent all at once; if the threshold is not reached within the aging period, the cached entry information is sent and the corresponding cached entry is deleted. This reduces the number of transmissions between matrix units, alleviates source-end hotspot congestion, reduces bandwidth consumption, and improves IPFIX concurrent processing speed and memory utilization.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0011] Figure 1 A flowchart illustrating a distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 4 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 5 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 6 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 7 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 8A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of shared SRAM space allocation provided in an embodiment of the present invention; Figure 10 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention; Figure 11 A schematic diagram of the architecture of a forwarding device provided in an embodiment of the present invention; Figure 12 This is a schematic diagram of the structure of a distributed IPFIX data stream processing device provided in an embodiment of the present invention; Figure 13 This is a hardware structure diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0012] The exemplary embodiments will now be described in detail. When the description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification; they are merely exemplary embodiments of apparatuses and methods consistent with some aspects of this specification.

[0013] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” used in this specification are also intended to include the plural forms unless the context clearly indicates otherwise. This specification may use terms such as “first,” “second,” “third,” etc., to describe various information or structural modules for the purpose of more clearly describing the scheme, and should not be construed as indicating or implying relative importance or implicitly specifying the number, order, or position of the indicated technical features. Thus, a feature defined with “first,” “second,” “third,” etc., may explicitly or implicitly include one or more of that feature. In the description of this specification, unless otherwise stated, “multiple” means two or more; “if” can be interpreted as “when,” “when,” or “in response to a determination.” In this specification, “and / or” is used to describe the relationship between related objects, indicating that three relationships may exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural.

[0014] To address the problems existing in the prior art, this application proposes a distributed IPFIX data stream processing mechanism. The core design concept of this application includes the following three aspects: First, a matrix-distributed architecture is adopted. IPFIX matrix units are distributed in a matrix on the chip, and these units are interconnected via an on-chip network (NOC). Each matrix unit contains a stream request initiation module and an entry storage module. When a stream request is initiated, a hash algorithm is used to calculate the storage address of the actual entry. When the storage address is calculated in another matrix unit, the data is transmitted via the NOC. This distributed architecture distributes the stream table storage load across multiple matrix units, preventing a single storage unit from becoming a bottleneck.

[0015] Second, a dual congestion mitigation mechanism is designed. At the source end, a local cache is set up to aggregate and statistically analyze requests flowing to the same destination matrix unit. When the statistical count reaches a threshold or the aging time expires, aggregated information is sent to the destination matrix unit via the NOC (Network Controller) to reduce the number of NOC transmissions. At the destination end, when congestion is detected, the storage address is recalculated by adjusting the hash calculation parameters, and subsequent requests are redirected to other uncongested matrix units, achieving load balancing.

[0016] Third, implement dynamic SRAM space reuse. The IPFIX table entry space and the packet forwarding table entry space (port table, routing table, MAC table, VLAN table, etc.) share the same physical SRAM, and the allocation ratio between the two is dynamically adjusted based on the occupancy status of the forwarding device's packet forwarding table entry space. When the forwarding device is lightly loaded, the IPFIX quota is increased to support fine-grained flow sampling; when the forwarding device is heavily loaded, the IPFIX space is reduced while reserving a minimum amount of space to ensure that forwarding functions take priority.

[0017] Optionally, this embodiment aims to address the issues of insufficient memory and limited concurrent processing capabilities in traditional single-chip IPFIX implementations, and is suitable for forwarding device chip scenarios requiring high-concurrency traffic monitoring. In environments such as data centers and enterprise campus networks, multiple ports simultaneously generate a large number of flow table entry requests, which a single storage unit cannot handle. This embodiment uses a matrix distributed architecture to distribute flow table storage and statistical tasks across multiple IPFIX matrix units, utilizes on-chip network NOC to achieve cross-unit transmission, and introduces cache aggregation and hash redirection mechanisms to improve the system's concurrent processing capabilities and memory utilization efficiency.

[0018] It should be noted that the forwarding device can be, but is not limited to, network devices such as switches, routers, gateways, and load balancers. In one implementation, the forwarding device can be a chassis switch or box switch that supports multi-port parallel processing; in another implementation, the forwarding device can be a forwarding chip that integrates the IPFIX matrix unit of this example. This forwarding chip is deployed in the network device and interconnects the matrix units through an on-chip network (NOC) to complete the distributed processing of IPFIX data streams in a hardware-accelerated manner.

[0019] Specifically, this embodiment provides a method for processing IPFIX data streams in a distributed forwarding device. The forwarding device is deployed with IPFIX matrix units distributed in a matrix, and these IPFIX matrix units can be interconnected via NOC (Network on Chip). Figure 1 This is a flowchart illustrating a distributed IPFIX data stream processing method provided in an embodiment of the present invention. (See attached diagram.) Figure 1 The method includes: Step 100: Receive message streams through the local IPFIX matrix unit.

[0020] Optionally, when data packets enter the aforementioned forwarding device, the local IPFIX matrix unit receives the packet stream. This packet stream may include network data packets forwarded via various ports of the forwarding device. Each IPFIX matrix unit is responsible for processing the packet stream of its corresponding port or port group.

[0021] Step 101: Based on the first hash calculation parameters, perform hash calculation on the flow identifier information of the message flow to determine the storage address of the first table entry.

[0022] Optionally, after receiving the aforementioned packet stream, the local IPFIX matrix unit extracts the flow identification information (e.g., 5-tuple or 7-tuple information) of the packet stream and performs a hash calculation on the flow identification information based on a preset first hash calculation parameter (e.g., hash seed value) to obtain the storage address of the first entry. The storage address of the first entry is used to indicate the location where the IPFIX entry corresponding to the aforementioned packet stream should be stored.

[0023] Step 102: Determine the matrix cell to which the first entry belongs based on its storage address.

[0024] Optionally, the local IPFIX matrix unit determines the IPFIX matrix unit to which the address belongs based on the storage address of the first entry mentioned above, using an address mapping algorithm. For example, the matrix unit number can be determined by performing a modulo operation or segmented mapping on the storage address of the first entry.

[0025] Step 103: When the storage address of the first entry belongs to the local IPFIX matrix unit, store and count the entries in the local IPFIX matrix unit.

[0026] Optionally, if step 102 determines that the storage address of the first entry belongs to the local IPFIX matrix unit itself, the local IPFIX matrix unit directly creates or updates the corresponding entry in its local entry storage module to record the statistical information of the packet flow (such as packet count, byte count, etc.).

[0027] Step 104: When the storage address of the first entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows direct transmission, the flow request is transmitted to the destination IPFIX matrix unit corresponding to the storage address of the first entry for entry storage and statistics.

[0028] Optionally, if step 102 determines that the storage address of the first entry belongs to another IPFIX matrix unit, the local IPFIX matrix unit can transmit the flow request to the destination IPFIX matrix unit via the on-chip network (NOC). Upon receiving the flow request, the destination IPFIX matrix unit creates or updates an entry at the storage address of the first entry it maintains, recording the statistical information of the aforementioned message flow.

[0029] Step 105: When the storage address of the first entry belongs to another IPFIX matrix unit and the other IPFIX matrix unit allows caching, the local IPFIX matrix unit aggregates and counts the flow requests flowing to the destination IPFIX matrix unit through caching. When the number of statistics reaches the threshold, the aggregated entry information is sent to the destination IPFIX matrix unit.

[0030] Optionally, if the storage address of the first entry belongs to another IPFIX matrix unit, this application provides the following possible implementation methods to determine whether the other IPFIX matrix unit belongs to "allow direct transmission" or "allow caching".

[0031] There are several ways to determine whether "other IPFIX matrix units" are allowed to transmit directly or be cached, such as through hotkeys or configuration switches.

[0032] Optionally, for a local IPFIX matrix unit, it can maintain a hotkey value corresponding to each other IPFIX matrix unit, for example, four IPFIX matrix units (numbered 1-4). The hotkey value is configured as "3". Then, if the storage address of the first entry of a certain packet flow belongs to IPFIX matrix unit-3, it matches the hotkey value "3". Then, IPFIX matrix unit-3 is "allowed for direct transmission". Then, step 104 is executed, and the flow request is immediately sent to unit-3 via NOC for real-time entry statistics.

[0033] Similarly, if the address of another packet stream belongs to IPFIX matrix unit -4, it does not match the hotkey value "3". In this case, IPFIX matrix unit -4 is "caching allowed". Then, step 105 is executed to add it to the local cache.

[0034] It should be noted that this hotkey value can be static or dynamic. For dynamic hotkey values, the hotkey value can be automatically updated by continuously counting the number of flow requests to each destination unit, so that the key value always points to the IPFIX matrix unit that is currently accessed most frequently.

[0035] Optionally, for each IPFIX matrix unit, a corresponding switch bit (such as a 1-bit register bit) can be configured, with bit 1 indicating "allow direct transmission" and bit 0 indicating "allow buffering". When the address of the packet stream belongs to another IPFIX matrix unit, step 104 or step 105 is determined by identifying the switch bit of that other IPFIX matrix unit.

[0036] The distributed IPFIX data stream processing method provided in this invention uses a matrix distributed architecture to distribute IPFIX functionality across multiple matrix units, achieving load balancing for flow table storage. The storage address of the first entry is determined through hash calculation, and storage is performed locally or remotely based on the address, avoiding centralized access bottlenecks from a single storage unit and reducing access latency during multi-port parallel processing. Simultaneously, a local cache aggregation mechanism is introduced to batch aggregate multiple flow requests destined for the same unit. When the statistical count reaches a threshold, the aggregated entry information is sent all at once; when the statistical count does not reach the threshold within the aging time, the cached entry information is sent to the corresponding destination IPFIX matrix unit, and the corresponding cached entry is deleted. These mechanisms work synergistically to significantly reduce the number of transmissions between matrix units, alleviate source-end hotspot congestion, reduce bandwidth occupancy, improve IPFIX concurrent processing speed, enhance memory utilization, and, when full traffic monitoring is required on some critical ports, utilize the shared storage of the distributed system to alleviate processing pressure and improve overall speed.

[0037] Optionally, in Figure 1 Building upon the previous method, this application also provides a redirection mechanism for potential congestion in the destination IPFIX matrix unit. This example is applicable to scenarios where the destination IPFIX matrix unit becomes congested due to excessive requests, such as traffic bursts on a specific port or concentrated access to a specific hash segment. By setting a congestion register at the source end and dynamically adjusting the hash calculation parameters, subsequent requests are distributed to other uncongested matrix units, achieving dynamic load balancing. Figure 1 On this basis, Figure 2 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention is shown below. Figure 2 It also includes: Step 106: When the destination IPFIX matrix unit is congested, adjust the first hash calculation parameter to the second hash calculation parameter, re-hash the packet flow based on the second hash calculation parameter, determine the storage address of the second table entry, and redirect subsequent requests to other IPFIX matrix units corresponding to the storage address of the second table entry.

[0038] Optionally, the local IPFIX matrix unit sets a congestion register in its control register area. This congestion register maintains a congestion status bit for each reachable destination IPFIX matrix unit, recording whether the destination unit is currently in a congested state. Initially, the congestion status bits of all destination IPFIX matrix units are set to uncongested.

[0039] Optionally, after the local IPFIX matrix unit sends a flow request to the destination IPFIX matrix unit via NOC, it receives a reply message from the destination IPFIX matrix unit. If the reply message contains destination congestion information (such as the congestion flag being set), the local IPFIX matrix unit updates the congestion status bit of the corresponding destination unit in the congestion register, marking it as congested.

[0040] Optionally, when the congestion register indicates that a destination IPFIX matrix unit is in a congested state, the local IPFIX matrix unit increases the first hash calculation parameter (such as the hash seed value) by a preset step size (such as +1) to obtain the second hash calculation parameter. This preset step size can be configured and adjusted according to the actual traffic model.

[0041] Optionally, the local IPFIX matrix unit re-hashes the flow identification information of the packet flow based on the second hash calculation parameter to obtain a second entry storage address that is different from the first entry storage address. This second entry storage address corresponds to other uncongested IPFIX matrix units, thereby redirecting subsequent requests to this unit and avoiding continuous access to congested destination units.

[0042] This embodiment effectively solves the hotspot congestion problem at the NOC destination by dynamically adjusting hash calculation parameters. The congestion register settings enable the local IPFIX matrix unit to perceive the load status of the destination IPFIX matrix unit in real time. When congestion is detected, hash parameter adjustments are immediately triggered, transferring subsequent requests from congested units to uncongested units, achieving dynamic load balancing. Redirection during congestion is handled autonomously by hardware, resulting in fast response times. Combined with the cache aggregation mechanism described above, the hotspot problems at both the source and destination ends are resolved, significantly improving the overall stability and concurrent processing capabilities of the distributed IPFIX system.

[0043] Optionally, this embodiment is a detailed explanation of the hash calculation process in the above example. In IPFIX implementation, how accurately and efficiently the flow identifier is extracted from the packet and hashed directly affects the uniformity of table entry storage and query efficiency. This embodiment is suitable for scenarios requiring accurate identification and fast addressing of network flows, such as data center traffic analysis and network security monitoring. By defining the specific content of the flow identifier information and the hash calculation method, it ensures that each network flow can be uniquely identified and uniformly mapped to the storage address space. Figure 1 On this basis, Figure 3 A flowchart illustrating another distributed implementation-based IPFIX data stream processing method for a forwarding device provided in this embodiment of the invention is shown below. Figure 3 Step 101 includes: Step 101-1: Extract the flow identifier information of the message flow.

[0044] Optionally, after receiving a packet flow, the aforementioned local IPFIX matrix unit extracts flow identification information from the packet header. In one possible implementation, the flow identification information includes the five-tuple information of the packet flow, namely, source IP address, destination IP address, source port number, destination port number, and transport layer protocol type. In another possible implementation, the flow identification information includes seven-tuple information, that is, adding VLAN identifier and ingress interface information to the above five-tuple. The flow identification information is used to uniquely identify a network flow.

[0045] Step 101-2: Based on the first hash calculation parameter, perform hash calculation on the flow identifier information to obtain the storage address of the first table entry.

[0046] Optionally, the local IPFIX matrix unit takes the first hash calculation parameter (such as the hash seed value) and the flow identification information as input, and calculates the first entry storage address using a hash algorithm (such as CRC32, MurmurHash, etc.). The first entry storage address is an address in the local storage address space of the IPFIX matrix unit, used to indicate the storage location of the flow entry.

[0047] This embodiment achieves accurate identification and uniform address mapping of network flows by defining the specific content of flow identifier information and the hash calculation method. Using 5-tuples or 7-tuples as flow identifiers can cover the differentiation requirements of most network flows, ensuring uniqueness between different flows. By selecting appropriate hash algorithms and hash seed values, flow identifiers can be uniformly mapped to the storage address space, reducing the probability of hash collisions and improving the efficiency of table entry storage and retrieval. Uniform address distribution also helps avoid localized overheating of the storage space. Combined with the distributed architecture in the example above, this makes the load on each matrix unit more balanced, thereby further improving the overall system's concurrent processing capabilities and memory utilization efficiency.

[0048] Optionally, this embodiment is a detailed explanation of the cache aggregation statistics process in the above example. In a distributed IPFIX architecture, when multiple ports and multiple matrix units simultaneously access a destination matrix unit, it often causes IPFIX processing congestion, affecting overall traffic processing. This embodiment, by setting a local cache in the source matrix unit, aggregates multiple requests that originally needed to be transmitted separately through the NOC into a single batch message, effectively reducing NOC congestion and improving concurrent processing capabilities. Figure 1 On this basis, Figure 4 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention is shown below. Figure 4 Step 105 includes: Step 105-1: Set up a cache in the local IPFIX matrix unit to record the number of flow requests to each destination IPFIX matrix unit.

[0049] Optionally, the local IPFIX matrix unit allocates a buffer area in its local memory to temporarily record flow requests that need to be routed to other IPFIX matrix units. This buffer is indexed by destination IPFIX matrix unit, with each destination IPFIX matrix unit corresponding to a buffer entry that records the number of pending flow requests for that destination unit and related statistics.

[0050] Step 105-2: Set the aging time for each destination IPFIX matrix unit in the cache and monitor the statistical count within the aging time.

[0051] Optionally, to prevent an accumulation of too many expired requests in the cache, the local IPFIX matrix unit sets an aging time (e.g., 100ms) for each cache entry. During the aging time, the request statistics of the corresponding destination IPFIX matrix unit are continuously monitored.

[0052] Step 105-3: When the number of statistics reaches the threshold within the aging time, send the aggregated table entry information to the corresponding destination IPFIX matrix unit.

[0053] Optionally, the aggregated table entry information includes, but is not limited to, the flow identifier information of each packet flow, the corresponding statistical information (such as packet count, byte count) and the storage address information of the first table entry, based on which the destination IPFIX matrix unit creates or updates table entries in batches.

[0054] Optionally, when the number of cached entries reaches a preset threshold (e.g., 16 requests) within the aforementioned aging time, the local IPFIX matrix unit sends an aggregation message to the corresponding destination IPFIX matrix unit via NOC, sending multiple flow requests accumulated in the cache in batches at once, thereby significantly reducing the number of NOC transmissions.

[0055] Step 105-4: When the number of statistics does not reach the threshold within the aging time, send the cached table entry information to the corresponding destination IPFIX matrix unit and delete the corresponding cached table entry.

[0056] Optionally, when the aging time expires and the number of statistics does not reach the aforementioned threshold, it indicates that the current traffic of the destination IPFIX matrix unit is low, and batch aggregation is unnecessary. In this case, the local IPFIX matrix unit sends the cached entries to the corresponding destination IPFIX matrix unit individually, then deletes the corresponding cached entries, releasing cache space. This individual sending mechanism ensures that flow information is not lost in low-traffic scenarios, while also promptly reclaiming cache resources.

[0057] This embodiment effectively solves the problem of NOC source-side hotspot congestion in a distributed IPFIX architecture through a local cache aggregation mechanism. A cache is set up, with cache entries indexed by destination IPFIX matrix units, allowing multiple requests flowing to the same destination IPFIX matrix unit to be temporarily accumulated and statistically analyzed. A threshold-triggered mechanism sends multiple NOC messages in batches once a certain number of requests have accumulated, significantly reducing the number of NOC transmissions and network load. The introduction of an aging time prevents the long-term accumulation of invalid entries for low-traffic destination IPFIX matrix units in the cache, ensuring efficient use of cache space. When traffic is low and the statistical count has not reached the threshold within the aging time, the local IPFIX matrix unit still sends the cached entries to the corresponding destination IPFIX matrix unit and then deletes the corresponding cached entries. This ensures that flow information is not lost in low-traffic scenarios, maintains the integrity of traffic statistics, and avoids long-term cache space occupation for low-traffic destination IPFIX matrix units, improving the utilization efficiency of cache resources. Optionally, this embodiment is a detailed explanation of the congestion redirection process in the above example. The caching method addresses hotspot congestion at the NOC source end, but if the hotspot is at the NOC destination end, it can slow down the overall chip processing speed and cause backpressure within the chip. This embodiment is suitable for scenarios where the destination matrix unit becomes congested due to receiving too many requests, such as a traffic surge on a specific port or concentrated access to a specific hash segment. By setting a congestion register at the source end and dynamically adjusting the hash calculation parameters, subsequent requests are redirected to other uncongested matrix units, achieving load balancing. Figure 2 On this basis, Figure 5 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention is shown below. Figure 5 Step 106 includes: Step 106-1: Set a congestion register in the local IPFIX matrix unit to record the congestion status of each destination IPFIX matrix unit.

[0058] Optionally, the local IPFIX matrix unit sets a congestion register in its control register area. This congestion register maintains a congestion status bit for each reachable destination IPFIX matrix unit, recording whether the destination unit is currently in a congested state. Initially, the congestion status bits of all destination IPFIX matrix units are set to uncongested.

[0059] Optionally, the congestion register can be an array of status bits set in the local IPFIX matrix unit control register area, with 1 bit corresponding to each destination IPFIX matrix unit to record the congestion status of the destination unit; initially, all bits are set to 0, indicating no congestion; when congestion information is received from the destination IPFIX matrix unit, the corresponding bit is set to 1, indicating congestion; when congestion recovery information is received, the corresponding bit is cleared to 0.

[0060] Step 106-2: When a flow request is sent to the destination IPFIX matrix unit through the on-chip network NOC and a reply is received, if the reply contains congestion information at the destination, the congestion register is updated.

[0061] Optionally, after the local IPFIX matrix unit sends a flow request to the destination IPFIX matrix unit via NOC, it receives a reply message from the destination IPFIX matrix unit. If the reply message contains destination congestion information (such as the congestion flag being set), the local IPFIX matrix unit updates the congestion status bit of the corresponding destination unit in the congestion register, marking it as congested.

[0062] Optionally, the destination IPFIX matrix unit determines whether it is congested based on the depth of its internal queue of pending requests or the processing latency. When the queue depth exceeds a preset congestion threshold, it determines that it is in a congested state and carries congestion information in the reply message returned to the local IPFIX matrix unit. By adopting a mechanism in which the destination end makes its own determination and feeds back to the source end, congestion monitoring and redirection response are completed in a closed loop at the hardware level.

[0063] Step 106-3: When the congestion register indicates that the destination IPFIX matrix unit is congested, increase the value of the first hash calculation parameter by a preset step size to obtain the second hash calculation parameter.

[0064] Optionally, when the congestion register indicates that a destination IPFIX matrix unit is in a congested state, the local IPFIX matrix unit increases the first hash calculation parameter (such as the seed value) by a preset step size (such as +1) to obtain the second hash calculation parameter. This preset step size can be configured and adjusted according to the actual traffic model.

[0065] Step 106-4: Based on the second hash calculation parameters, recalculate the hash of the message stream to determine the storage address of the second table entry.

[0066] Optionally, the local IPFIX matrix unit re-hashes the flow identification information of the packet flow based on the second hash calculation parameter to obtain a second entry storage address that is different from the first entry storage address. This second entry storage address corresponds to other uncongested IPFIX matrix units, thereby redirecting subsequent requests to this unit and avoiding continuous access to congested destination units.

[0067] Optionally, the aforementioned local IPFIX matrix unit, while increasing the value of the first hash calculation parameter by a preset step to obtain the second hash calculation parameter, records the number of times the hash parameter is adjusted. This number of adjustments is used for the upper limit control judgment in subsequent step 107.

[0068] This embodiment effectively solves the problem of hotspot congestion at the NOC destination by dynamically adjusting hash calculation parameters. The congestion register settings enable the local IPFIX matrix unit to perceive the load status of the destination IPFIX matrix unit in real time. When congestion is detected, hash parameter adjustments are immediately triggered, transferring subsequent requests from congested units to uncongested units, achieving dynamic load balancing. Hash redirection during congestion is handled autonomously by hardware, resulting in a fast response time. After congestion recovery, the CPU performs entry merging and space release, forming a hardware-software collaborative congestion mitigation closed loop. Combined with the cache aggregation mechanism in the previous example, this addresses hotspot issues at both the source and destination ends, significantly improving the overall stability and concurrent processing capabilities of the distributed IPFIX system.

[0069] Optionally, this embodiment further illustrates the upper limit control mechanism for hash calculation parameter adjustment based on the above example. In actual operation, if congestion persists after multiple hash parameter adjustments, it indicates that the forwarding device is already in a state of full-chip congestion, and further adjustment of hash parameters will have limited effect. This embodiment is applicable to extremely high-load scenarios, such as surges in full-chip traffic or DDoS attacks. By setting an adjustment upper limit, meaningless hash adjustments are avoided under severe congestion conditions, reducing system overhead and reporting the problem to upper-layer software or CPU processing. Figure 5 On this basis, Figure 6 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention is shown below. Figure 6 The method also includes: Step 107: When the number of times the first hash calculation parameter is adjusted reaches the preset upper limit and the corresponding IPFIX matrix unit is still congested, stop adjusting the first hash calculation parameter.

[0070] Optionally, the local IPFIX matrix unit records the number of adjustments each time it adjusts the first hash calculation parameter. When the number of adjustments reaches a preset upper limit (e.g., +3), the adjustment of the hash calculation parameter stops even if the destination IPFIX matrix unit still reports congestion. This is because if congestion persists after multiple adjustments (e.g., seed+1, +2, +3), it indicates that the forwarding device is already in a state of full chip congestion. In this case, further adjustments to the hash parameter have limited effect and require intervention from upper-layer software or the CPU. By setting the preset upper limit, meaningless hash adjustments can be avoided under severe congestion conditions, reducing system overhead.

[0071] This embodiment effectively prevents ineffective computation and resource waste in extreme congestion scenarios by setting an upper limit for hash calculation parameter adjustments. Under normal circumstances, dynamic hash redirection can quickly distribute requests to uncongested units, alleviating local hotspots. However, when the forwarding device as a whole is in a state of full chip congestion, any local hash adjustment cannot fundamentally solve the problem; continued adjustments will only increase unnecessary computational overhead and state maintenance costs. By setting a preset upper limit (e.g., the seed can be adjusted up to +3), the system can promptly stop meaningless adjustments after reasonable attempts, reserving processing resources for more critical tasks, while triggering intervention from upper-layer software or the CPU to adopt higher-level congestion control strategies. This mechanism ensures the system's robustness in the face of extreme traffic surges and avoids further performance degradation caused by blind retries.

[0072] Optionally, this embodiment further illustrates the entry merging mechanism after congestion recovery, based on the above example. During congestion, the first and second entry storage addresses of the same packet flow may each store partial statistical information, resulting in the same flow table being stored in two SRAM addresses. After congestion recovery, the statistical values ​​from the two addresses need to be merged, and the space occupied by the second address needs to be released. This embodiment is applicable to data consistency recovery scenarios after congestion mitigation, ensuring the integrity of traffic statistics and effective reclamation of memory space. Figure 5 On this basis, Figure 7 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention is shown below. Figure 7 The method also includes: Step 108: The target IPFIX matrix unit monitors the number of flow requests within the time window. When the number of flow requests decreases to the release threshold, congestion recovery is determined, and the congestion recovery information is reported to the CPU.

[0073] Optionally, the destination IPFIX matrix unit continuously monitors the number of flow requests received within a preset time window (e.g., 10ms). When the number of flow requests decreases to a release threshold (e.g., 50% of the congestion trigger threshold), it is determined that congestion has been resolved. At this time, the destination IPFIX matrix unit reports the congestion recovery information to the CPU. To avoid frequent switching between congestion state triggering and release, the congestion trigger threshold is usually set higher than the release threshold.

[0074] Optionally, to avoid frequent switching between congestion state triggering and release, on the one hand, the congestion triggering threshold is usually set higher than the release threshold, forming a hysteresis interval; on the other hand, the above congestion recovery determination adopts a collaborative confirmation mechanism.

[0075] Specifically, the destination IPFIX matrix unit maintains a congestion feedback record to record the local IPFIX matrix units that have sent destination congestion information. When the destination IPFIX matrix unit carries destination congestion information in its reply message to a local IPFIX matrix unit, it records the identifier of that local IPFIX matrix unit in the aforementioned congestion feedback record. Since the local IPFIX matrix unit only updates its congestion register and adjusts its hash calculation parameters after receiving destination congestion information, the aforementioned congestion feedback record covers all local IPFIX matrix units that have performed redirection.

[0076] The destination IPFIX matrix unit continuously monitors the number of flow requests within a time window. When the number of flow requests decreases to the release threshold, the destination IPFIX matrix unit only determines that the local load has decreased and, based on the aforementioned congestion feedback record, sends a congestion recovery probe notification to each local IPFIX matrix unit in the record. Upon receiving the notification, the local IPFIX matrix unit rolls back the second hash calculation parameter to the first hash calculation parameter, remapping subsequent requests to the first table entry storage address, and replies with an acknowledgment message to the destination IPFIX matrix unit. After receiving acknowledgment messages from each local IPFIX matrix unit in the aforementioned congestion feedback record and detecting that the number of flow requests remains stable below the release threshold, the destination IPFIX matrix unit ultimately determines that congestion has recovered, reports the congestion recovery information to the CPU, triggers the table entry merging operation in step 109 of the example above, and clears the aforementioned congestion feedback record. Optionally, after sending the congestion recovery probe notification, the destination IPFIX matrix unit starts an acknowledgment timer. If no acknowledgment message is received from a local IPFIX matrix unit after a preset acknowledgment timeout, it is considered that the local IPFIX matrix unit has rolled back. By using a dual-condition interlock between local IPFIX matrix unit rollback confirmation and destination IPFIX matrix unit load detection, frequent switching caused by occasional load fluctuations is effectively avoided.

[0077] Step 109: The CPU reads the first table entry corresponding to the storage address of the first table entry and the second table entry corresponding to the storage address of the second table entry, and merges the statistical value of the second table entry into the first table entry.

[0078] Optionally, during congestion, the first and second entry storage addresses of the same packet stream may each store partial statistical information. Once congestion is resolved, the CPU accesses the first and second entry storage addresses to read the corresponding first and second entries, respectively. The CPU then accumulates and merges the statistical values ​​(such as packet count, byte count, etc.) from the second entry into the first entry, ensuring the integrity and consistency of the statistical data.

[0079] Optionally, since the first hash calculation parameters (such as the hash seed value) and hash calculation formula can be pre-configured and maintained by the CPU, when the local IPFIX matrix unit performs congestion redirection based on the second hash calculation parameters, the CPU can automatically calculate the corresponding second entry storage address based on the same flow identifier information and the adjusted hash calculation parameters. Therefore, after congestion recovery, the CPU does not need to rely on the local IPFIX matrix unit to maintain or report redirection records. It can determine the first and second entry storage addresses that need to be merged based on the known hash calculation parameters and flow identifier information, and read the corresponding first and second entries respectively, merging the statistical value of the second entry into the first entry.

[0080] Step 110: Release the table space occupied by the storage address of the second table entry.

[0081] Optionally, after the merge operation is completed, the statistics stored in the second entry's storage address are no longer needed. The CPU releases the entry space occupied by the second entry's storage address and marks it as free so that it can be subsequently reallocated to new IPFIX flow entries.

[0082] Optionally, in addition to performing the congestion recovery processing in steps 108-110, the aforementioned target IPFIX matrix unit can also periodically scan the IPFIX entries it maintains to monitor the aging status of each entry. When an entry is not updated within a preset aging time, it is determined that the flow has ended, the statistical information of the entry is reported to the CPU, and the storage space occupied by the entry is released for use by new IPFIX flow entries.

[0083] Optionally, when the aforementioned target IPFIX matrix unit detects a packet drop event, it reports the currently counted flow table entries and the reason for the drop to the CPU, which then performs software-level anomaly handling or traffic analysis to ensure the integrity of the statistical data and the monitorability of the network status.

[0084] This embodiment ensures data consistency and memory reclamation in the distributed IPFIX system after congestion relief through congestion recovery monitoring and entry merging mechanisms. The destination monitors changes in the number of flow requests via a time window, employing a hysteresis design where the trigger threshold is higher than the release threshold. This avoids frequent switching of congestion states near the boundary, improving system stability. After congestion recovery, the CPU uniformly reads entries from the first and second addresses and merges the statistical values, ensuring the integrity of statistical information for the same flow. After merging, the space occupied by the second address is released promptly to prevent memory fragmentation and waste. This mechanism, together with the dynamic hash redirection in the previous example, forms a complete closed loop: redirection and diversion during congestion, merging and reclamation after congestion recovery. This solves performance issues during congestion and ensures data correctness and resource reclaimability after congestion recovery, enabling the system to operate stably under various load conditions.

[0085] Optionally, this embodiment aims to address the memory resource waste caused by the fixed allocation of IPFIX entry space and packet forwarding table entry space. During the operation of the forwarding device, the demand for the two types of entry space changes dynamically under different load conditions: under light load, the forwarding table entries occupy less space, and IPFIX can occupy more space to support fine-grained sampling; under heavy load, the routing table, MAC table, etc., expand rapidly, and IPFIX needs to give up space to ensure forwarding functionality. This embodiment improves the overall memory utilization efficiency through SRAM sharing and dynamic adjustment. Figure 8 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention is shown below. Figure 8 The method also includes: Step 111: Share the same physical static random access memory (SRAM) between the IPFIX entry space and the message forwarding entry space.

[0086] Optionally, in a forwarding device, the IPFIX table space and the packet forwarding table space (including port tables, routing tables, MAC tables, VLAN tables, etc.) can share the same physical SRAM. This SRAM is managed through a unified address space, and the NOC routing module and address access can use both table spaces interchangeably. By sharing the same physical SRAM, the allocation ratio of the two table spaces can be dynamically adjusted according to actual needs, improving memory utilization efficiency.

[0087] Optionally, Figure 9 This is a schematic diagram illustrating a shared SRAM space allocation according to an embodiment of the present invention. See also... Figure 9The left figure illustrates the shared SRAM space allocation when the forwarding device is under light load. In this state, the occupancy rate of the packet forwarding table entry space (including port table, routing table, MAC table, VLAN table, etc.) is low, and there is spare space in the shared SRAM. Correspondingly, the IPFIX entry space receives a larger allocation quota, which can support finer-grained flow sampling. The right figure illustrates the shared SRAM space allocation when the forwarding device is under heavy load. In this state, the occupancy rate of the packet forwarding table entry space increases due to the rapid expansion of routing tables, MAC tables, etc. The system dynamically reduces the allocation quota of the IPFIX entry space, allocates the freed SRAM space to packet forwarding table entries, but retains the minimum reserved space for IPFIX to ensure that the core IPFIX traffic billing function is not affected. The IPFIX entry space and the packet forwarding table entry space share the same physical SRAM, and the range of the two areas is dynamically divided by the space boundary pointer. The forwarding device adjusts the space boundary pointer online according to the load status, realizing the flexible reuse of the two entry spaces without reserving a fixed-size independent area for each.

[0088] Optionally, the aforementioned message forwarding table entry space may not include Access Control List (ACL) entries. These ACL entries can be implemented using a Tri-State Content Addressable Memory (TCAM), whose storage architecture differs from the shared SRAM described above, and therefore may not be included in the dynamic reuse scope.

[0089] Step 112: Dynamically adjust the allocation ratio between IPFIX table space and packet forwarding table space based on the occupancy status of the packet forwarding table space of the forwarding device.

[0090] Optionally, the forwarding device dynamically adjusts the allocation ratio of IPFIX table entry space and packet forwarding table entry space in the shared SRAM based on the current overall load status. For example, when the forwarding device is under light load, the forwarding table entries occupy less space, so the IPFIX table entry space quota can be increased to support finer-grained flow sampling; when the forwarding device is under heavy load, the routing table, MAC table, etc., expand rapidly, and the system automatically allocates SRAM space to packet forwarding functions to ensure that forwarding functions are not interrupted.

[0091] Optionally, since the IPFIX entry space and the packet forwarding entry space share the same physical SRAM, read and write accesses from both may occur simultaneously. This SRAM is equipped with an access arbitration mechanism to schedule access requests from the IPFIX matrix unit and the packet forwarding module, ensuring the orderly execution of read and write operations and avoiding data inconsistencies caused by access conflicts.

[0092] Step 113: When it is necessary to adjust the size of the IPFIX table entry, stop the packet flow and reconfigure the table entry allocation.

[0093] Optionally, when a forwarding device needs to adjust the allocation ratio between IPFIX entry space and packet forwarding entry space (e.g., switching from a light-load to a heavy-load state, or vice versa), packet flow processing must first be stopped to avoid entry access conflicts or data inconsistencies during the adjustment process. Then, the software can re-issue the entry allocation configuration and update the SRAM space partition boundaries. After the configuration takes effect, normal packet flow processing resumes. The operations of stopping the packet flow and re-issuing the configuration are controlled by the control plane (such as upper-layer management software or a hardware state machine).

[0094] Alternatively, in another implementation, to avoid stopping the packet flow when adjusting the IPFIX entry space, the forwarding device divides the IPFIX entry space in the shared SRAM into a currently active region and a pre-configuration region. When the size of the IPFIX entry space needs to be adjusted, the control plane writes the new entry allocation configuration into the pre-configuration region and updates the space boundary pointer. The IPFIX matrix unit determines the range of the currently active region according to the space boundary pointer and continues to process the entry storage and statistics of the packet flow. After the pre-configuration region is written, the control plane triggers an atomic switch operation to switch the space boundary pointer from the currently active region to the pre-configuration region, making the new configuration effective. The IPFIX matrix unit accesses the entry space according to the new boundary pointer in subsequent packet processing. The currently active region and the pre-configuration region take turns serving as the active region and the pre-configuration region, respectively. Online configuration updates are achieved through atomic pointer switching without stopping the packet flow.

[0095] This embodiment breaks through the limitations of low memory resource utilization in the traditional fixed partitioning mode by sharing the IPFIX entry space and the packet forwarding entry space with the same physical SRAM. Unified address space management and universal NOC routing module access enable flexible allocation of the two entry spaces without the need to reserve a fixed-size independent area for each. The allocation ratio is dynamically adjusted according to the occupancy status of the packet forwarding entry space of the forwarding device. Under light load, IPFIX can obtain more space to support fine-grained flow sampling (such as increasing from 1:1000 to 1:100), enhancing security monitoring and operational visibility; under heavy load, priority is given to ensuring the entry space required for forwarding functions to ensure uninterrupted network operation. This elastic allocation strategy allows limited SRAM resources to be dynamically optimized according to actual business needs, significantly improving overall memory utilization efficiency while ensuring the stability of the two core functions of traffic monitoring and packet forwarding.

[0096] Optionally, this embodiment is a detailed explanation of the dynamic adjustment process in the above example. Accurately determining the load status of the forwarding device and formulating a reasonable space adjustment strategy accordingly is key to the SRAM dynamic reuse mechanism. This embodiment is applicable to scenarios where the allocation of IPFIX and forwarding function resources needs to be adjusted in real time according to network load. By monitoring indicators such as the total occupancy rate of packet forwarding table entries and the number of hash collision iterations, it determines whether the forwarding device is currently under light or heavy load and performs corresponding space adjustment operations. Figure 8 On this basis, Figure 10 A flowchart illustrating another distributed IPFIX data stream processing method provided in an embodiment of the present invention is shown below. Figure 10 Step 112 includes: Step 112-1: Monitor the percentage of remaining space in the message forwarding table.

[0097] Optionally, the forwarding device calculates the remaining space percentage of the packet forwarding table entry space by monitoring the occupied percentage. For example, when the total capacity of the packet forwarding table entry space is 100% and 30% is occupied, the remaining space percentage is 70%. This remaining space percentage directly reflects the current demand pressure of the forwarding function on SRAM resources and is a reliable basis for determining whether the IPFIX entry space can be expanded.

[0098] Optionally, to avoid misjudgment caused by accidental fluctuations at a single sampling point, the forwarding device can collect occupancy rate samples at multiple times within a preset monitoring window, and take the average or median as the basis for calculating the remaining percentage, thereby improving the stability of the judgment.

[0099] Step 112-2: When the remaining space of the message forwarding table is greater than the preset percentage, increase the IPFIX table space quota.

[0100] Optionally, when the remaining space in the packet forwarding table is greater than a preset percentage (e.g., the first preset percentage = 50%), it indicates that the forwarding function is currently using relatively little SRAM resources and has a large amount of spare space. In this case, the forwarding device allocates the spare SRAM space in the packet forwarding table to the IPFIX table space, increasing the IPFIX memory usage quota. For example, the IPFIX table space can be increased from the normal 20% quota to 40%, thereby supporting finer-grained flow sampling and enhancing security monitoring and operational visibility.

[0101] Optionally, when increasing the IPFIX entry space quota, the forwarding device adjusts the position of the space boundary pointer to move the end boundary of the packet forwarding entry space to the free area, thereby expanding the range between the start and end boundaries of the IPFIX entry space and realizing the flexible division of the two entry spaces.

[0102] Step 112-3: When the remaining space of the message forwarding table is less than the preset percentage, reduce the IPFIX table space.

[0103] Optionally, when the remaining space in the packet forwarding table is less than a preset percentage (e.g., the second preset percentage = 20%), it indicates that the forwarding function is currently consuming a large amount of SRAM resources, and the remaining space is tight. In this case, the forwarding device reduces the quota of IPFIX table entries, but retains a minimum reserved space (e.g., 20% of the normal quota) to ensure that the core traffic billing function of IPFIX is not affected. The freed SRAM space is allocated to the packet forwarding table entries to ensure that the forwarding function takes priority.

[0104] Optionally, when reducing the IPFIX entry space, the forwarding device also achieves this by adjusting the position of the space boundary pointer. If the occupied proportion of the packet forwarding table entry space continues to rise, the space boundary pointer moves towards the IPFIX entry space, compressing the available range of the IPFIX entry space and supplementing the packet forwarding table entry space with the released SRAM space.

[0105] This embodiment uses the percentage of remaining space in the packet forwarding table as a quantitative indicator, making the dynamic adjustment of SRAM space more explicit and predictable. When there is sufficient space, the IPFIX quota is increased to support fine-grained stream sampling; when there is limited space, the IPFIX space is compressed to ensure forwarding functionality. This strategy of improving sampling accuracy under light load and prioritizing forwarding under heavy load allows the same SRAM to adaptively adjust according to actual network needs, significantly improving the overall utilization efficiency of memory resources while ensuring stable system operation under different load conditions.

[0106] Optionally, in another implementation, the threshold judgment mechanism used in steps 112-1 to 112-3 above can be optimized by combining hash collision monitoring. When maintaining the packet forwarding table entry space, the forwarding device uses the hash collision iteration count to help determine the space tightness: when the hash collision iteration count is within the normal range, it indicates that the hash table space is sufficient; when the hash collision iteration count frequently exceeds the preset number, it indicates that the hash table space is approaching saturation, even if the remaining space ratio has not yet dropped to an extremely low level, it means that effective slots are scarce. The forwarding device can simultaneously monitor both the remaining space ratio and the hash collision iteration count, which complement each other. When both indicators simultaneously indicate space tightness, it can more accurately trigger adjustments to the IPFIX table entry space.

[0107] It should be noted that since the IPFIX entry space and the packet forwarding entry space share the same SRAM, and a hash algorithm is used to map keywords to storage locations in the SRAM, a hash collision will occur when multiple keywords are mapped to the same hash bucket. In this case, iterative search (such as the kick-out-relocation mechanism of Cuckoo Hash) is needed to find an empty slot to complete the insertion.

[0108] Optionally, to avoid frequent switching of IPFIX entry space at the boundary between capacity expansion and reduction, the aforementioned preset percentage can further employ a dual-threshold hysteresis mechanism, including a first preset percentage (triggering the capacity expansion threshold) and a second preset percentage (triggering the capacity reduction threshold), with the first preset percentage being greater than the second preset percentage. For example, when the remaining capacity percentage rises above 60%, it is determined that the conditions for capacity expansion are met; when it falls below 20%, it is determined that the conditions for capacity reduction are met; and when it is between the two, the status quo is maintained. The aforementioned dual-threshold hysteresis mechanism forms a buffer zone between capacity expansion and reduction, effectively avoiding the back-and-forth switching of the allocation ratio due to occasional fluctuations in network traffic, and improving the stability of system operation.

[0109] Optionally, to better illustrate the above example, a possible implementation architecture for a forwarding device is provided below. Specifically, Figure 11 This is a schematic diagram of the architecture of a forwarding device provided in an embodiment of the present invention. See also: Figure 11 The forwarding device comprises a 2×2 matrix consisting of four IPFIX matrix units, which are interconnected via an on-chip network of objects (NOC). Each IPFIX matrix unit includes a flow request initiation module, an NOC routing module, and an entry storage module.

[0110] Each IPFIX matrix unit is connected to the on-chip network NOC through its NOC routing module. When the destination IPFIX matrix unit of the flow request is another matrix unit, the NOC routing module of the local IPFIX matrix unit routes the flow request to the on-chip network NOC, and then transmits it to the NOC routing module of the destination IPFIX matrix unit.

[0111] If IPFIX matrix unit-1 is the local IPFIX matrix unit in the above example, and IPFIX matrix unit-3 is the destination IPFIX matrix unit in the above example, then IPFIX matrix unit-2 and IPFIX matrix unit-4 are other IPFIX matrix units in the above example.

[0112] In one example, the local IPFIX matrix unit (IPFIX matrix unit-1) performs a hash calculation on the packet flow based on the first hash calculation parameter to determine the storage address of the first entry. If the storage address of the first entry belongs to the local IPFIX matrix unit (IPFIX matrix unit-1) itself, then the local IPFIX matrix unit (IPFIX matrix unit-1) also acts as the destination IPFIX matrix unit corresponding to the packet flow, directly creating or updating the corresponding entry in its entry storage module. At this time, IPFIX matrix unit-2, IPFIX matrix unit-3, and IPFIX matrix unit-4 all belong to other IPFIX matrix units.

[0113] In another example, if the first entry storage address belongs to the destination IPFIX matrix unit (IPFIX matrix unit-3), then the local IPFIX matrix unit (IPFIX matrix unit-1) transmits the flow request to the destination IPFIX matrix unit (IPFIX matrix unit-3) through its NOC routing module and on-chip network NOC. Upon receiving the flow request, the destination IPFIX matrix unit (IPFIX matrix unit-3) creates or updates an entry at the first entry storage address maintained in its entry storage module. At this time, IPFIX matrix units-2 and-4 belong to other IPFIX matrix units.

[0114] In another example, suppose the destination IPFIX matrix unit (IPFIX matrix unit-3) experiences congestion. The local IPFIX matrix unit (IPFIX matrix unit-1) adjusts the first hash calculation parameter to the second hash calculation parameter, recalculates the hash based on the second hash calculation parameter, and determines the storage address of the second entry. If the storage address of this second entry belongs to IPFIX matrix unit-4, then IPFIX matrix unit-4 becomes the destination IPFIX matrix unit after the packet flow is redirected, and the local IPFIX matrix unit (IPFIX matrix unit-1) redirects subsequent flow requests to IPFIX matrix unit-4 through the NOC routing module and the on-chip network NOC. At this time, IPFIX matrix units-2 and IPFIX matrix units-3 belong to other IPFIX matrix units.

[0115] It should be noted that in the various examples of this application, the destination IPFIX matrix unit is determined by the storage address of the first entry, and is not a fixed unit.

[0116] To perform the steps of the above examples and achieve the corresponding technical effects, this application provides an implementation method for a distributed forwarding device IPFIX data stream processing apparatus. Specifically, Figure 12This is a schematic diagram of a distributed IPFIX data stream processing device provided in an embodiment of the present invention. See also... Figure 12 The device 20 is deployed in a forwarding device, which has IPFIX matrix units distributed in a matrix. Each IPFIX matrix unit of the device 20 includes a flow request initiation module 200, a NOC routing module 201, and an entry storage module 202.

[0117] The flow request initiation module 200 is used to receive the packet flow, perform hash calculation on the flow identification information of the packet flow based on the first hash calculation parameter, determine the storage address of the first table entry, and determine the matrix unit to which it belongs based on the storage address of the first table entry. When the storage address of the first table entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows caching, the flow request initiation module 200 is also used to aggregate and count the flow requests flowing to the destination IPFIX matrix unit through caching.

[0118] NOC routing module 201 is used to transmit flow requests to the destination IPFIX matrix unit corresponding to the first entry storage address when the first entry storage address belongs to another IPFIX matrix unit and the other IPFIX matrix unit allows direct transmission; when the number of statistics reaches a threshold, NOC routing module 201 is also used to send aggregated entry information to the destination IPFIX matrix unit.

[0119] The table entry storage module 202 is used to store and count entries in the local IPFIX matrix unit when the first table entry storage address belongs to the local IPFIX matrix unit; and to store and count entries in the destination IPFIX matrix unit when the first table entry storage address belongs to another IPFIX matrix unit.

[0120] Optionally, the flow request initiation module 200 is further configured to adjust the first hash calculation parameter to the second hash calculation parameter when the destination IPFIX matrix unit is congested, and re-hash the packet flow based on the second hash calculation parameter to determine the storage address of the second table entry; The NOC routing module 201 is also used to redirect subsequent requests to other IPFIX matrix units corresponding to the second entry storage address when the destination IPFIX matrix unit is congested. Optionally, the stream request initiation module 200 is specifically used to extract the stream identifier information of the message stream, perform hash calculation on the stream identifier information based on the first hash calculation parameter, and obtain the storage address of the first table entry.

[0121] Optionally, the flow request initiation module 200 is specifically configured to: set up a cache to record the number of flow requests to each destination IPFIX matrix unit; set an aging time for each destination IPFIX matrix unit in the cache and monitor the statistical count within the aging time; when the statistical count reaches a threshold within the aging time, trigger the NOC routing module 201 to send the aggregated entry information to the corresponding destination IPFIX matrix unit; when the statistical count does not reach the threshold within the aging time, send the cached entry information to the corresponding destination IPFIX matrix unit and delete the corresponding cached entry.

[0122] Optionally, the flow request initiation module 200 is specifically used to set a congestion register in the local IPFIX matrix unit to record the congestion status of each destination IPFIX matrix unit; when a flow request is sent to a destination IPFIX matrix unit through the NOC routing module 201 and a reply is received, if the reply contains destination congestion information, the congestion register is updated; when the congestion register indicates that the destination IPFIX matrix unit is congested, the value of the first hash calculation parameter is increased by a preset step size to obtain the second hash calculation parameter; based on the second hash calculation parameter, the packet flow is re-hash-calculated to determine the storage address of the second entry.

[0123] Optionally, the flow request initiation module 200 is also used to stop adjusting the first hash calculation parameter when the number of times the first hash calculation parameter is adjusted reaches a preset upper limit and the corresponding IPFIX matrix unit is still congested.

[0124] See also Figure 12 The device 20 also includes a CPU 203, and multiple IPFIX matrix units can all be used as target IPFIX matrix units.

[0125] Correspondingly, the destination IPFIX matrix unit is used to monitor the number of flow requests within the time window. When the number of flow requests decreases to the release threshold, congestion recovery is determined, and the congestion recovery information is reported to the CPU 203 through the NOC routing module 201 and the on-chip network NOC. The CPU 203 is used to read the first table entry corresponding to the first table entry storage address and the second table entry corresponding to the second table entry storage address, merge the statistical value of the second table entry into the first table entry, and release the table space occupied by the second table entry storage address.

[0126] Optionally, the entry storage module 202 is also used to share the same physical static random access memory (SRAM) with the packet forwarding table entry space; and to dynamically adjust the allocation ratio of the IPFIX entry space and the packet forwarding table entry space according to the occupancy status of the packet forwarding table entry space of the forwarding device. When it is necessary to adjust the size of the IPFIX entry space, the packet flow is stopped and the entry allocation configuration is reconfigured.

[0127] Optionally, the entry storage module 202 is also used to monitor the remaining percentage of the message forwarding entry space; when the remaining percentage of the message forwarding entry space is greater than a preset percentage, the IPFIX entry space quota is increased; when the remaining percentage of the message forwarding entry space is less than a preset percentage, the IPFIX entry space is decreased.

[0128] Accordingly, this specification also provides an apparatus that can be applied to computer devices, such as servers or terminal devices. The apparatus can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logically defined apparatus, it is formed by a processor reading the corresponding computer program instructions from non-volatile memory into memory and executing them. From a hardware perspective… Figure 13 A hardware structure diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 13 The diagram shown is a hardware structure diagram of an electronic device containing the device provided in this specification, except... Figure 13 In addition to the processor 310, memory 330, network interface 320, and non-volatile memory 340 shown, the server, electronic device, or forwarding device where the device 331 is located in the embodiment may also include other hardware depending on the actual function of the electronic device, which will not be described in detail here.

[0129] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0130] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative, and the modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0131] The foregoing has described exemplary embodiments of this specification. It should be understood that in some cases, the modules described in this specification may be divided in a manner different from that in the embodiments, and the described actions or steps may be performed in a different order than that in the embodiments, while still achieving the desired result. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0132] The above are merely preferred embodiments of this specification and are not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification shall be included within the scope of protection of this specification.

Claims

1. A distributed IPFIX data stream processing method, characterized in that, The method is applied to a forwarding device, which is deployed with IP flow information output IPFIX matrix units distributed in a matrix pattern. The method includes: Receive message streams through the local IPFIX matrix unit; Based on the first hash calculation parameters, a hash calculation is performed on the flow identifier information of the message flow to determine the storage address of the first table entry; The matrix cell to which the first entry belongs is determined based on its storage address. When the storage address of the first entry belongs to the local IPFIX matrix unit, the entry is stored and counted in the local IPFIX matrix unit. When the storage address of the first entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows direct transmission, the flow request is transmitted to the destination IPFIX matrix unit corresponding to the storage address of the first entry for entry storage and statistics. When the storage address of the first entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows caching, the local IPFIX matrix unit aggregates and counts the flow requests flowing to the destination IPFIX matrix unit through caching. When the number of counts reaches a threshold, the aggregated entry information is sent to the destination IPFIX matrix unit.

2. The method according to claim 1, characterized in that, Also includes: When the destination IPFIX matrix unit is congested, the first hash calculation parameter is adjusted to the second hash calculation parameter, the packet flow is re-hash calculated based on the second hash calculation parameter, the second table entry storage address is determined, and subsequent requests are redirected to other IPFIX matrix units corresponding to the second table entry storage address.

3. The method according to claim 1, characterized in that, The step of aggregating and statistically analyzing flow requests destined for the destination IPFIX matrix unit through caching in the local IPFIX matrix unit includes: A cache is set in the local IPFIX matrix unit to record the number of flow requests flowing to each destination IPFIX matrix unit; Set an aging time for each destination IPFIX matrix unit in the cache, and monitor the statistical count within the aging time; When the statistical quantity reaches the threshold within the aging time, the aggregated entry information is sent to the corresponding destination IPFIX matrix unit. When the statistical quantity does not reach the threshold within the aging time, the cached entry information is sent to the corresponding destination IPFIX matrix unit, and the corresponding cached entry is deleted.

4. The method according to claim 2, characterized in that, The step of adjusting the first hash calculation parameter to the second hash calculation parameter when the destination IPFIX matrix unit is congested includes: A congestion register is set in the local IPFIX matrix unit to record the congestion status of each destination IPFIX matrix unit; When a flow request is sent to the destination IPFIX matrix unit via the on-chip network NOC and a reply is received, if the reply contains destination congestion information, the congestion register is updated. When the congestion register indicates that the destination IPFIX matrix unit is congested, the value of the first hash calculation parameter is increased by a preset step size to obtain the second hash calculation parameter; Based on the second hash calculation parameters, the message stream is re-hash-calculated to determine the storage address of the second table entry.

5. The method according to claim 4, characterized in that, Also includes: The target IPFIX matrix unit monitors the number of flow requests within the time window. When the number of flow requests decreases to the release threshold, congestion recovery is determined, and the congestion recovery information is reported to the CPU. The CPU reads the first entry corresponding to the storage address of the first entry and the second entry corresponding to the storage address of the second entry, and merges the statistical value of the second entry into the first entry; Release the table space occupied by the storage address of the second table entry.

6. The method according to claim 1, characterized in that, Also includes: The IPFIX entry space and the message forwarding entry space share the same physical static random access memory (SRAM). The allocation ratio between the IPFIX entry space and the packet forwarding table entry space is dynamically adjusted based on the occupancy status of the packet forwarding table entry space of the forwarding device. When it is necessary to adjust the size of the IPFIX table entry, stop the packet flow and reconfigure the table entry allocation.

7. The method according to claim 6, characterized in that, The step of dynamically adjusting the allocation ratio between the IPFIX entry space and the packet forwarding table entry space based on the occupancy status of the packet forwarding table entry space of the forwarding device includes: Monitor the percentage of remaining space in the message forwarding table; When the remaining space of the message forwarding table is greater than the preset percentage, the IPFIX table space quota is increased; When the remaining space of the message forwarding table is less than the preset percentage, the IPFIX table space is reduced.

8. A distributed IPFIX data stream processing device, deployed in a forwarding device, characterized in that, The device is equipped with IPFIX matrix units arranged in a matrix, each IPFIX matrix unit including a flow request initiation module, a NOC routing module, and an entry storage module. The device includes: The flow request initiation module is used to receive a packet flow, perform a hash calculation on the packet flow based on a first hash calculation parameter, determine the storage address of a first table entry, and determine the matrix unit to which the first table entry belongs based on the storage address of the first table entry. When the storage address of the first table entry belongs to another IPFIX matrix unit, and the other IPFIX matrix unit allows caching, the flow request initiation module is also used to aggregate and count the flow requests flowing to the destination IPFIX matrix unit through caching. The NOC routing module is used to transmit the flow request to the destination IPFIX matrix unit corresponding to the first entry storage address when the first entry storage address belongs to another IPFIX matrix unit and the other IPFIX matrix unit allows direct transmission; when the number of statistics reaches a threshold, the NOC routing module is also used to send the aggregated entry information to the destination IPFIX matrix unit. The table entry storage module is used to store and count entries in the local IPFIX matrix unit when the first table entry storage address belongs to the local IPFIX matrix unit; and to store and count entries in the table entry storage module of the destination IPFIX matrix unit when the first table entry storage address belongs to another IPFIX matrix unit.

9. The apparatus according to claim 8, characterized in that, The flow request initiation module is further configured to, when the destination IPFIX matrix unit is congested, adjust the first hash calculation parameter to a second hash calculation parameter, recalculate the hash of the packet flow based on the second hash calculation parameter, and determine the storage address of the second entry. The NOC routing module is also used to redirect subsequent requests to other IPFIX matrix units corresponding to the storage address of the second entry.

10. An electronic device, characterized in that, Including memory and processor; Memory, used to store one or more programs; When the one or more programs are executed by the processor, the method as described in any one of claims 1 to 7 is implemented.

Images