A multi-level homologous session traffic aggregation method and system

Abstract

This invention relates to the field of traffic aggregation technology, specifically a multi-level same-source session traffic aggregation method and system. The method extracts the five-tuple information of each data packet and generates a session identifier, calculates the session feature vector and session priority score. At the first aggregation level, each service interface board establishes a local session table; data packets from high-priority sessions are aggregated first based on the session priority score. At the second aggregation level, each service interface board synchronizes its local session table to the chassis-level session table; data packets with the same session identifier are forwarded to the same output port. At the third aggregation level, the chassis-level session table is synchronized to the global session table; data packets from other chassis are redirected to the corresponding output port of the main aggregation node determined based on session affinity; all data packets with the same session identifier are output from the same output port and a session integrity report is generated; thus ensuring the integrity and consistency of session data.

Description

Technical Field

[0001] This invention relates to the field of traffic aggregation technology, specifically a method and system for multi-level same-source session traffic aggregation. Background Technology

[0002] In large-scale distributed network environments, network traffic monitoring and analysis systems typically require the deployment of multiple data acquisition devices to cover different network links and access points, enabling comprehensive collection of network traffic. Session traffic aggregation is a key technology in network traffic analysis; its core lies in the complete collection and correlation of all data packets belonging to the same communication session, thereby accurately analyzing and identifying session behavior.

[0003] However, in real-world distributed network deployments, due to the complexity of network topology and the diversity of traffic paths, data packets for the same session are often transmitted through different network links, resulting in their distribution across different service interface boards, chassis, and even different physical devices for collection. This decentralized collection method leads to severe fragmentation of session data; data packets belonging to the same session are separated across different devices and storage locations, making effective correlation and aggregation impossible. This results in incomplete and discontinuous session data received by the backend analysis system, severely impacting the accuracy and effectiveness of network behavior analysis, threat detection, and traffic auditing.

[0004] Therefore, there is an urgent need for a method that can efficiently aggregate same-origin session traffic in a multi-level distributed architecture to ensure the integrity and consistency of session data, thereby improving the overall performance and accuracy of network traffic analysis systems. Summary of the Invention

[0005] (1) Technical problems to be solved

[0006] The purpose of this invention is to provide a method and system for multi-level same-source session traffic aggregation to solve the problem of fragmented and incomplete session data caused by the traffic of the same session being collected in a distributed network and distributed to different devices and links.

[0007] (2) Technical solution

[0008] To achieve the above objectives, in one aspect, the present invention provides a method for multi-level same-origin session traffic aggregation, the method comprising:

[0009] S1. Collect network traffic from different links through multiple service interface boards to obtain several data packets; extract the five-tuple information of each data packet; extract data packet features in the edge computing unit of each service interface board, and calculate the session feature vector based on the five-tuple information and data packet features; calculate the session priority score based on the session feature vector; generate a session identifier based on the five-tuple information, and mark data packets with the same five-tuple information as same-source session traffic.

[0010] S2. At the first aggregation level, each service interface board establishes a local session table, which records the session identifier, five-tuple information, session priority score, and session status; and aggregates data packets of high-priority sessions according to the session priority score.

[0011] S3. At the second aggregation level, each service interface board synchronizes the local session table to the chassis-level session table; dynamically adjusts the adaptive hash weight according to the load status of each output port; and forwards data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight.

[0012] S4. At the third aggregation level, each chassis synchronizes the chassis-level session table to the global session table; for cross-chassis same-source session traffic, the session affinity is calculated based on the session identifier and the output port load status of each chassis, and a chassis is determined as the main aggregation node based on the session affinity, and data packets with the same session identifier on other chassis are redirected to the corresponding output port of the main aggregation node.

[0013] S5. Calculate the adaptive aging time based on the data packet arrival time interval and session activity. When the session idle time exceeds the adaptive aging time, delete the session from the session table. Output all data packets belonging to the same session identifier from the same output port to the backend analysis system and generate a session integrity report.

[0014] Furthermore, the method of forwarding data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight includes:

[0015] After each service interface board receives a data packet and generates a session identifier, it queries the chassis-level session table to determine whether the session identifier already has an output port mapping relationship. If the session identifier does not have an output port mapping relationship, it obtains the adaptive hash weight corresponding to each output port, performs a hash operation on the five-tuple information of the session identifier to obtain a hash value, divides the hash value space into multiple weight intervals according to the adaptive hash weight of each output port, determines the target output port according to the weight interval into which the hash value falls, and establishes an output port mapping relationship between the session identifier and the target output port in the chassis-level session table. If the session identifier already has an output port mapping relationship, it retrieves the target output port corresponding to the session identifier from the chassis-level session table.

[0016] The service interface board calculates the forwarding path through the switching plane based on the target output port; encapsulates the data packet with a forwarding instruction, which includes a session identifier, a target output port identifier, and forwarding path information; and sends the data packet and forwarding instruction to the service interface board where the target output port is located through the switching plane; the service interface board where the target output port is located parses the forwarding instruction and verifies the consistency of the mapping relationship between the session identifier and the output port; and uses the same output port mapping relationship and forwarding path for subsequent data packets with the same session identifier.

[0017] Furthermore, the method for obtaining the target output port corresponding to the session identifier from the chassis-level session table includes:

[0018] Obtain the target output port corresponding to the session identifier and the current load status of the target output port from the chassis-level session table; when the current load status of the target output port does not exceed the preset load threshold, directly use the target output port as the forwarding destination of the data packet.

[0019] When the current load of the target output port exceeds a preset load threshold, the session priority score and session status corresponding to the session identifier are obtained from the chassis-level session table. When the session priority score is higher than the preset migration priority threshold and the session status is active, the adaptive hash weights corresponding to each output port are re-obtained, output ports whose current load exceeds the preset load threshold are excluded, and a new target output port is re-determined from the remaining output ports according to the adaptive hash weights. The output port mapping relationship between the session identifier and the new target output port is updated in the chassis-level session table, and a session migration notification is sent to the original target output port. When the session priority score is not higher than the preset migration priority threshold or the session status is inactive, the original target output port is retained.

[0020] Furthermore, the method for re-determining the new target output port based on the adaptive hash weight among the remaining output ports includes:

[0021] Obtain the adaptive hash weights of all remaining output ports, calculate the migration cost between the original target output port and each remaining output port, and calculate the migration cost by weighting the number of hops, path bandwidth and current path congestion level between two output ports in the switching plane topology; calculate the session migration sensitivity based on the number of transmitted data packets and session duration recorded in the chassis-level session table based on the session identifier.

[0022] The migration adaptability of each remaining output port is calculated by weighting the adaptive hash weight, migration cost, and session migration sensitivity. The remaining output port with the highest migration adaptability is selected as the new target output port.

[0023] Furthermore, the method of calculating session affinity based on session identifier and the load status of each chassis's output port, determining a chassis as a primary aggregation node based on the session affinity, and redirecting data packets with the same session identifier from other chassis to the corresponding output port of the primary aggregation node includes:

[0024] Obtain the data packet distribution information of the same session identifier on each chassis from the global session table, and count the number of data packets belonging to the session identifier received by each chassis; calculate the data packet carrying ratio of each chassis based on the number of data packets; obtain the output port load status of each chassis, including the current bandwidth utilization and data packet forwarding delay of the output port.

[0025] The session affinity of each chassis is calculated based on the data packet carrying ratio and the output port load status. The session affinity characterizes the association strength between the chassis and the session. The chassis with the highest session affinity is selected as the main aggregation node. When multiple chassis have the same highest session affinity, the chassis carrying the most session data packets is selected as the main aggregation node.

[0026] After determining the primary aggregation node, a redirection command is sent to other chassis. The redirection command includes a session identifier, a primary aggregation node identifier, and target output port information. Upon receiving the redirection command, other chassis query their local chassis-level session table and identify data packets belonging to the session identifier. They then forward subsequently received data packets with the session identifier to the primary aggregation node via cross-chassis links. After receiving data packets forwarded from other chassis, the primary aggregation node merges them with data packets with the same session identifier collected by its own chassis and outputs them through the same output port.

[0027] Furthermore, the method for calculating the session affinity of each chassis based on the data packet carrying ratio and the output port load status includes:

[0028] The ratio of the current bandwidth utilization rate of each chassis's output port to the preset bandwidth baseline value is used as the bandwidth load factor, and the ratio of the data packet forwarding delay to the preset delay baseline value is used as the delay load factor; the comprehensive load factor of the output port is calculated based on the bandwidth load factor and the delay load factor.

[0029] The session priority score corresponding to the session identifier is obtained from the global session table. The packet carrying ratio weight coefficient and the output port load comprehensive factor weight coefficient are determined based on the session priority score. The carrying weight value is calculated based on the packet carrying ratio and its corresponding weight coefficient. The load weight value is calculated based on the output port load comprehensive factor and its corresponding weight coefficient. The original session affinity value of each chassis is calculated based on the carrying weight value and the load weight value. The original session affinity values ​​of all chassis are normalized to obtain the session affinity of each chassis.

[0030] Furthermore, the method for calculating the adaptive aging time based on the data packet arrival time interval and session activity, and deleting the session from the session table when the session idle time exceeds the adaptive aging time, includes:

[0031] The session table records the most recent data packet arrival timestamp for each session identifier. When a new data packet belonging to the session identifier is received, the data packet arrival time interval is calculated based on the arrival timestamp of the new data packet and the most recent data packet arrival timestamp. The data packet arrival time interval is then stored in the time interval history record of the corresponding session identifier in the session table.

[0032] The mean and variance of the arrival time intervals of each data packet in the time interval history are calculated, and the time interval stability coefficient is calculated based on the mean and variance of the arrival time intervals. The session activity is calculated based on the total number of data packets received by the session identifier and the data packet arrival time intervals. The session priority score corresponding to the session identifier is obtained from the session table, and the aging time base value and adjustment coefficient are determined based on the session priority score. The initial aging time is calculated based on the aging time base value, the time interval stability coefficient, and the adjustment coefficient. The adaptive aging time of the session identifier is calculated based on the initial aging time and the session activity. The time difference between the current timestamp and the most recent data packet arrival timestamp of the session identifier is monitored in real time as the session idle time. When the session idle time exceeds the adaptive aging time, the session record corresponding to the session identifier is deleted from the local session table, the chassis-level session table, or the global session table, and the relevant resources are released.

[0033] Furthermore, the method for determining the aging time baseline value and adjustment coefficient based on the session priority score includes:

[0034] The session priority score is compared with multiple preset priority score thresholds to determine the priority level corresponding to the session identifier; the corresponding aging time base value is retrieved from a preset aging time base value mapping table according to the priority level; the session duration and the number of transmitted data packets corresponding to the session identifier are obtained from the session table; the session duration is compared with a preset duration threshold to obtain a duration impact factor, and the number of transmitted data packets is compared with a preset data packet number threshold to obtain a data volume impact factor; a session state comprehensive factor is calculated based on the duration impact factor and the data volume impact factor; and an adjustment coefficient is obtained by weighting the priority level and the session state comprehensive factor.

[0035] On the other hand, based on the same inventive concept, this invention also provides a multi-level homogeneous session traffic aggregation system, the system comprising: a data packet acquisition and session identifier generation module, a first aggregation level processing module, a second aggregation level processing module, a third aggregation level processing module, and a session integrity report generation module, wherein each module is sequentially connected in communication.

[0036] The packet acquisition and session identifier generation module is used to acquire network traffic from different links through multiple service interface boards to obtain several data packets; extract the five-tuple information of each data packet; extract data packet features in the edge computing unit of each service interface board; calculate the session feature vector based on the five-tuple information and data packet features; calculate the session priority score based on the session feature vector; generate a session identifier based on the five-tuple information; and mark data packets with the same five-tuple information as same-source session traffic.

[0037] The first aggregation level processing module is used to establish a local session table for each service interface board at the first aggregation level. The local session table records session identifier, five-tuple information, session priority score and session status. Data packets of high-priority sessions are aggregated first according to the session priority score.

[0038] The second aggregation level processing module is used to synchronize the local session table to the chassis-level session table of each service interface board at the second aggregation level; dynamically adjust the adaptive hash weight according to the load status of each output port; and forward data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight.

[0039] The third aggregation level processing module is used to synchronize the chassis-level session table to the global session table in the third aggregation level; for cross-chassis same-source session traffic, it calculates session affinity based on session identifier and the output port load status of each chassis, determines a chassis as the main aggregation node based on the session affinity, and redirects data packets with the same session identifier on other chassis to the corresponding output port of the main aggregation node.

[0040] The session integrity report generation module is used to calculate the adaptive aging time based on the data packet arrival time interval and session activity. When the session idle time exceeds the adaptive aging time, the session is deleted from the session table. All data packets belonging to the same session identifier are output from the same output port to the backend analysis system, and a session integrity report is generated.

[0041] (3) Beneficial effects

[0042] Compared with the prior art, the beneficial effects of the present invention are:

[0043] 1. Through a multi-level aggregation mechanism, session tables are established at the business interface board, chassis, and global levels respectively. Based on session feature vectors, priority scores, and other information, precise aggregation processing is performed to ensure that traffic from the same source can be accurately aggregated. At the same time, adaptive hash weight and session affinity calculation methods ensure that data packets are forwarded to the output port in a reasonable manner, effectively improving the efficiency and accuracy of traffic aggregation.

[0044] 2. During traffic forwarding, the load status of the output port is fully considered. When the target output port is overloaded, the output port is re-determined based on conditions such as session priority and status. When aggregating across chassis, the session affinity is calculated based on the data packet carrying ratio and the load status of the output port to select the primary aggregation node. These measures achieve balanced distribution of system load and enhance the stability of the system under different load conditions.

[0045] 3. By calculating the adaptive aging time based on the data packet arrival time interval and session activity, idle session records are deleted in a timely manner and related resources are released, avoiding the invalid occupation of resources and ensuring the rational use of system resources. Attached Figure Description

[0046] Figure 1 This is a flowchart of a multi-level same-source session traffic aggregation method according to Embodiment 1 of the present invention.

[0047] Figure 2 This is a schematic diagram of the module composition of a multi-level homogeneous session traffic aggregation system according to Embodiment 2 of the present invention. Detailed Implementation

[0048] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] Before giving examples, it is necessary to explain the application scenarios of the present invention. The present invention is a multi-level same-source session traffic aggregation method and system, which is applied in a distributed network deployment scenario. Due to the complexity of the network topology and the diversity of traffic paths, the data packets of the same session are severely fragmented, resulting in incomplete and discontinuous session data received by the backend analysis system.

[0050] Example 1: As Figure 1 As shown in the figure, this embodiment provides a method for multi-level same-origin session traffic aggregation, the method including:

[0051] S1. Network traffic from different links is collected through multiple service interface boards to obtain several data packets; the five-tuple information of each data packet is extracted; data packet features are extracted in the edge computing unit of each service interface board, and a session feature vector is calculated based on the five-tuple information and data packet features; a session priority score is calculated based on the session feature vector; a session identifier is generated based on the five-tuple information, and data packets with the same five-tuple information are marked as same-source session traffic; traffic collection is performed through multiple service interface boards deployed at key network nodes. These service interface boards are connected to different network links. For example, in a typical data center deployment scenario, there may be 8 service interface boards connected to different ports of the core switch, the uplink of the server cluster, and the external Internet access point. Each service interface board is configured with network traffic mirroring or bypass acquisition functions, which can capture all data packets passing through its monitored link in real time. When a complete communication session occurs in the network, such as when a user accesses a web service through the HTTPS protocol, the data packets of this session may be transmitted through different links monitored by service interface boards No. 1, No. 3, and No. 5, respectively, due to network routing policies, load balancing mechanisms, or link redundancy designs. At this point, each of the three interface boards will collect a portion of the data packets belonging to the same session, forming a distributed collection state of session data. After the data packet collection is completed, each service interface board immediately extracts the five-tuple information from each captured data packet. The five-tuple refers to five key parameters that can uniquely identify a network session, specifically including the source IP address, destination IP address, source port number, destination port number, and transport layer protocol type. Edge computing units are usually composed of FPGAs or dedicated network processors, possessing hardware-level packet processing capabilities. The feature extraction process not only analyzes the basic header information of the data packets but also delves into application layer protocol characteristics, data packet size distribution, time interval patterns, etc. The session feature vector comprehensively reflects multiple aspects of the session's attributes. This is achieved by numerically encoding the IP address and port number in the five-tuple, for example, converting the IP address to a 32-bit integer and the port number itself to a 16-bit integer. Then, the extracted application layer protocol type is mapped to a protocol feature code, with HTTP corresponding to the value 80 and HTTPS corresponding to 443, etc. The data packet size is normalized to form a size feature component. The data packet interval is calculated by the time difference with the previous data packet in the same session. The purpose of priority scoring is to differentiate the importance of different sessions so that critical business traffic can be prioritized when resources are limited. The calculation method uses a weighted scoring mechanism, with weight coefficients for various characteristics pre-set according to business needs. For example, the traffic weight for the enterprise's internal OA system is set to 0.3, the traffic weight for the financial system is set to 0.9, and the weight for ordinary internet access is 0.1.For a specific session, if the feature vector shows that its destination port is port 8443, commonly used in the financial system, and the source IP address belongs to the financial department's network segment, then the session will be assigned a higher base score. For example, a financial system session might score 8.7 out of 10, while a regular web browsing session might score 3.2. Session identifier generation is the core step in achieving same-source traffic identification. Using a 5-tuple as input, a fixed-length session identifier is generated through a hash algorithm. Specifically, the five elements of the 5-tuple are concatenated into a byte string in a specific order, and then this string is hashed using SHA-256 to generate a 256-bit hash value. For ease of storage and retrieval, the first 128 or 64 bits of the hash value are typically used as the session identifier. The session identifier has extremely high uniqueness; the probability of different sessions generating the same identifier is close to zero. When any subsequent business interface board captures a data packet with the same 5-tuple information, it will generate the exact same session identifier. This ensures that even if the data packets come from different collection points, they can be accurately identified as same-source traffic belonging to the same session. All data packets with the same session identifier are marked with a uniform session label to facilitate subsequent aggregation processing.

[0052] S2. At the first aggregation level, each service interface board establishes a local session table. This local session table records the session identifier, five-tuple information, session priority score, and session status. Data packets from high-priority sessions are aggregated based on the session priority score. Upon entering the first aggregation level processing stage, each service interface board establishes and maintains a session table locally. This local session table is implemented using an efficient in-memory data structure, such as a hash table to support fast queries, with the session identifier as the primary key. Each record in the table corresponds to an active session, fully recording the key information of that session. The session status field indicates whether the session is currently active or idle, determined by whether any data packets have arrived within the last 5 seconds; if so, it is active; otherwise, it is idle. Additionally, it records statistical information such as the arrival time of the first packet, the arrival time of the last packet, the cumulative number of data packets, and the cumulative number of bytes for that session. When the No. 1 service interface board receives the data packet of session A7F3C8E2D5B6F901 for the first time, a new record is immediately created in the local session table. When the interface board subsequently captures data packets with the same session identifier, it only needs to update the statistics and last arrival time in the record, without recreating it. A priority-based aggregation processing strategy is implemented based on the local session table. Since the processing capacity and cache space of each service interface board are limited, when a large amount of session traffic is captured simultaneously, the processing order must be strategically arranged. Data packets from high-priority sessions are given priority and placed in the forwarding queue for processing. This is implemented by setting up a priority queue mechanism in the data packet processing flow of the service interface board. Assume there are four priority queues: an emergency queue (priority score of 8 or above), a high-priority queue (6-8 points), a normal queue (4-6 points), and a low-priority queue (below 4 points). When the aforementioned financial system session data packet (priority 8.7 points) arrives, it directly enters the emergency queue, while ordinary web browsing data packets (priority 3.2 points) enter the low-priority queue. When the processor polls these queues, it processes them in the order of urgent, high, normal, and low priority, and will not process low priority queues until all packets in the urgent queue have been processed. This ensures that critical business traffic can be processed in a timely manner even during peak traffic periods, preventing the loss or delay of important session data packets due to congestion.

[0053] S3. At the second aggregation level, each service interface board synchronizes its local session table to the chassis-level session table; dynamically adjusts the adaptive hash weight based on the load status of each output port; and forwards data packets with the same session identifier to the same output port via the switching plane according to the adaptive hash weight. The second aggregation level aggregates session traffic within the chassis. Modern network equipment typically adopts a chassis-based architecture, where multiple service interface boards can be installed within a single chassis. These interface boards are interconnected via a backplane switching plane. Each service interface board needs to periodically synchronize its maintained local session table to the chassis-level session table. The synchronization mechanism can use an incremental update method, whereby the service interface board only reports newly added session records or session records whose status has changed, instead of uploading the entire local table each time, thus significantly reducing synchronization overhead. The chassis-level session table is maintained by the chassis's main control board and uses a distributed shared storage structure, allowing all service interface boards to access it quickly. This globally visible session table integrates session information collected by all interface boards within the chassis, providing a unified view for cross-interface board traffic forwarding. In chassis-level aggregation, a key technology is calculating and using adaptive hash weights to determine the output port of a data packet. Adaptive hash weights refer to weight values ​​that are dynamically adjusted based on the real-time load status of each output port. Assuming the chassis has four output ports, in the initial system state, their loads are roughly balanced, and the weights can be evenly distributed as 0.25 each. However, as traffic changes, if it is detected that the bandwidth utilization of output port 1 has reached 85%, while ports 2, 3, and 4 are only at 40%, 35%, and 30% respectively, then the system needs to reduce the weight of port 1 and increase the weights of the other ports. The recalculated weight allocation is: port 1 0.1, port 2 0.3, port 3 0.3, port 4 0.3, with lower weights for higher loads.

[0054] S4. At the third aggregation level, each chassis synchronizes its chassis-level session table to the global session table. For cross-chassis same-source session traffic, session affinity is calculated based on the session identifier and the output port load status of each chassis. A chassis is determined as the primary aggregation node based on this affinity, and data packets with the same session identifier from other chassis are redirected to the corresponding output port of the primary aggregation node. The third aggregation level handles cross-chassis session traffic aggregation scenarios. In large-scale deployments, multiple chassis often need to work collaboratively. These chassis are connected via dedicated chassis interconnect links, forming a distributed system. Each chassis further synchronizes its chassis-level session table to the global session table. This global table is maintained by the system's centralized management node or synchronized between chassis using a distributed consistency protocol. The global session table provides a complete view of all sessions across the entire system, showing which chassis a particular session's data packets are distributed across.

[0055] S5. Calculate the adaptive aging time based on the data packet arrival time interval and session activity. When the session idle time exceeds the adaptive aging time, the session is deleted from the session table. All data packets belonging to the same session identifier are output to the backend analysis system from the same output port, and a session integrity report is generated. To prevent the session table from growing indefinitely and consuming excessive system resources, the system implements an adaptive aging mechanism to clean up session records that have been idle for a long time. After the above three-level aggregation process, all data packets belonging to the same session identifier are finally converged to the same output port and output to the backend analysis system from that port according to their original timing. The output port is connected to network traffic analysis equipment or security monitoring platforms. After receiving the complete session data stream, these backend systems can accurately reconstruct the communication process and perform functions such as protocol parsing, behavior analysis, and threat detection. To allow the backend systems to understand the aggregation quality of the session data, the system also generates a session integrity report. This report records the key indicators of each session, including: session identifier, total number of data packets in the session, data packet source distribution (indicating how many packets came from which interface boards and chassis), whether there is packet loss, packet sequence integrity, aggregation time, and other information. For example, for session A7F3C8E2D5B6F901, the integrity report would show: this session contains a total of 1000 data packets, of which 600 come from interface board 1 of chassis 1, 300 from interface board 3 of chassis 2, and 100 from interface board 2 of chassis 3. All data packets have been successfully aggregated without any packet loss. The time from the first packet acquisition to the completion of aggregation output is 127 milliseconds, and the session data integrity score is 100. The backend analysis system can use this report to determine the quality of data aggregation. Sessions with low integrity scores require special handling or alerts.

[0056] The method of forwarding data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight includes:

[0057] After each service interface board receives a data packet and generates a session identifier, it queries the chassis-level session table to determine if the session identifier already has an output port mapping relationship. If the session identifier does not have an output port mapping relationship, it obtains the adaptive hash weight corresponding to each output port, performs a hash operation on the five-tuple information of the session identifier to obtain a hash value, divides the hash value space into multiple weight intervals according to the adaptive hash weight of each output port, determines the target output port based on the weight interval into which the hash value falls, and establishes an output port mapping relationship between the session identifier and the target output port in the chassis-level session table. If the session identifier already has an output port mapping relationship, it retrieves the target output port corresponding to the session identifier from the chassis-level session table. During chassis-level aggregation, the forwarding of data packets depends on the output port mapping relationship maintained in the chassis-level session table. After the service interface board receives a data packet and extracts the five-tuple information to generate a session identifier, the primary task is to determine whether the session is appearing for the first time. This determination is accomplished by querying the chassis-level session table, specifically by performing a fast lookup in the index structure of the session table using the session identifier as the key. Suppose a service interface board receives a data packet with session identifier B8E4D9F3A6C7E102. It initiates a query request to the chassis-level session table, and the session table's query engine searches for this identifier in the hash index. If this is the first data packet of this session, no corresponding record exists in the session table, and the query returns an empty result, indicating that no output port mapping relationship has been established. When no mapping relationship exists for a session identifier, the system needs to allocate a suitable output port for it. This allocation process fully considers the requirements of load balancing. First, the adaptive hash weights of all available output ports in the chassis are obtained. Assuming the chassis is configured with 6 output ports, their current weights are: Port 1 0.20, Port 2 0.18, Port 3 0.16, Port 4 0.15, Port 5 0.15, and Port 6 0.16. These weight values ​​are dynamically calculated based on the real-time load of each port; ports with lighter loads receive higher weights, and vice versa. Next, a hash operation is performed on the five-tuple information of the session identifier. CRC32, MD5, or a custom hash function can be used. The key is to ensure that the same five-tuple always produces the same hash value. For example, if a five-tuple yields a hash value of 374582 after hashing, in order to map this hash value to a specific output port, the system divides the entire hash value space into multiple intervals according to weighted proportions.Assuming a 16-bit hash value is used, with a range of 0-65535, the intervals are divided according to the aforementioned weights: 0-13106 corresponds to port 1 (0.20%), 13107-24902 corresponds to port 2 (0.18%), 24903-35388 corresponds to port 3 (0.16%), 35389-45218 corresponds to port 4 (0.15%), 45219-55048 corresponds to port 5 (0.15%), and 55049-65535 corresponds to port 6 (0.16%). Therefore, 374582 falls within the interval 35414-45247, thus port 4 is determined as the target output port. The system then creates a new record in the chassis-level session table, establishing a mapping relationship between session identifier B8E4D9F3A6C7E102 and output port 4, and records information such as the mapping establishment time and initial load status. For sessions with established mapping relationships, the processing flow is more concise and efficient. When the service interface board queries the session table and finds that session identifier B8E4D9F3A6C7E102 already has a record, it directly reads the target output port information from the record. The data structure returned by the session table includes the target port number (4), the location of the service interface board where the port is located (e.g., port 4 is located on service interface board 7), and the validity identifier of the mapping relationship. The system does not need to recalculate hashes or weights, and directly uses the existing mapping relationship.

[0058] The service interface board calculates the forwarding path through the switching plane based on the target output port; it encapsulates the data packet with a forwarding instruction, which includes a session identifier, a target output port identifier, and forwarding path information; it then sends the data packet and forwarding instruction to the service interface board where the target output port is located via the switching plane; the service interface board where the target output port is located parses the forwarding instruction and verifies the consistency of the mapping relationship between the session identifier and the output port; it uses the same output port mapping relationship and forwarding path for subsequent data packets with the same session identifier. After obtaining the target output port information, the service interface board needs to calculate the forwarding path to that output port through the internal switching plane of the chassis. The topology of the switching plane determines the complexity of the path calculation. In a simple single-level switching architecture, there is a direct connection between any two interface boards, and path calculation only needs to determine the correspondence between the input and output ports of the switching matrix. For example, if a data packet is currently on interface board 3 and needs to be forwarded to port 4 of interface board 7, the path information is "Source: Board 3 - Switching Plane - Target: Board 7 Port 4". In a more complex multi-level switching architecture, it may need to go through multiple switching levels, and path calculation needs to consider the connection relationship and current load of each switching unit. Before being forwarded through the switching plane, data packets undergo encapsulation, a crucial step ensuring accurate arrival at the destination port. The encapsulation process adds an internal forwarding header to the original data packet, containing all the necessary information for the forwarding instruction. The forwarding instruction typically follows a fixed format, including several fields: First, a session identifier field, populated with the 64-bit identifier B8E4D9F3A6C7E102, used to verify packet ownership at the target board; second, the destination output port identifier, represented as a board number-port number tuple; third, forwarding path information, encoding the previously calculated switching path, possibly represented as a bit vector or skip list; fourth, a priority tag, copying the session's priority score from the session table to ensure high-priority packets receive priority during switching; and finally, a checksum field to detect errors in the forwarding header during transmission. A complete forwarding instruction may occupy 32-64 bytes and is appended to the original data packet to form an encapsulated frame. The encapsulated data packet is then sent to the switching plane for transmission. The switching plane operates similarly to an on-chip network. When a data packet enters a switching input port, the switching controller reads the path information in the forwarding header and configures the connection state of the switching matrix according to the first-hop destination. Taking a crossbar switching structure as an example, the controller sets the switching matrix so that input port 3 connects to output port 7, establishing a data path from board 3 to board 7. Data packets are transmitted along this path. In the case of multi-stage switching, the switching controller parses the next-hop indication in the path information at each stage and dynamically adjusts the switching connections.During transmission, high-priority data packets gain priority arbitration rights. When multiple ports compete for the same output channel simultaneously, high-priority data packets pass first, ensuring low-latency transmission of critical business traffic. After the data packet arrives at the No. 7 service interface board, its receiving and processing unit first parses the forwarding instruction. The parsing process extracts information from the forwarding header field by field: reading the session identifier (B8E4D9F3A6C7E102), reading the target port identifier (confirming it as port 4 of this board), and reading the priority label to obtain the priority score of the session. Consistency verification aims to ensure that the data packet should indeed be output from this port, preventing misdelivery of data packets due to forwarding errors or session table inconsistencies. The verification method involves the No. 7 board querying its locally cached chassis-level session table copy, retrieving the mapping record corresponding to the session identifier B8E4D9F3A6C7E102, and verifying whether the target port in the record is port 4. If the data packets match, the verification passes, and the data packet is allowed to enter the output queue of port 4. If an inconsistency is found, for example, if the session table shows that the session should output to port 5, an exception handling process is triggered. This may be because the session table has just been updated but has not yet been synchronized to the local copy. In this case, the latest session table information needs to be requested from the main control board, and the data packet processing method is determined based on the latest information. The processing flow for subsequent data packets with the same session identifier has been significantly optimized. Once the first data packet of a session completes the entire process from session identifier lookup, port allocation, path calculation to forwarding verification, this information is determined and recorded in the relevant session table. When interface board 3 receives the second, third, or even the Nth data packet of session B8E4D9F3A6C7E102, there is no need to repeat port allocation and path calculation; the determined output port mapping relationship (target: port 4 of board 7) and forwarding path information are directly read from the local cache. The service interface board maintains a fast forwarding cache for high-frequency sessions, using a design similar to a CPU cache, storing recently used session mapping information in on-chip high-speed memory. All subsequent data packets reuse the same output port mapping relationship and forwarding path, ensuring that all data packets in the entire session are accurately aggregated to port 4 of board 7, thus achieving the goal of session traffic aggregation within the chassis.

[0059] The method for obtaining the target output port corresponding to the session identifier from the chassis-level session table includes:

[0060] The system retrieves the target output port corresponding to the session identifier and its current load status from the chassis-level session table. When the current load status of the target output port does not exceed a preset load threshold, the target output port is directly used as the forwarding destination for data packets. After the system finds the target output port corresponding to the session identifier from the chassis-level session table, it does not simply use the port but further checks its current load status; this is a crucial step in achieving dynamic load balancing. The information retrieved from the session table includes not only the target port number but also real-time load monitoring data for that port. This load data is continuously collected by the service interface board where the output port is located and periodically updated to the session table, with an update cycle typically between 100 milliseconds and 1 second. Load status metrics include multiple dimensions: the port's current bandwidth utilization rate (the percentage of used bandwidth to total port bandwidth); the depth of the port's output queue, reflecting the backlog of data packets waiting to be sent; and the port's packet loss rate, indicating whether data packets are being dropped due to overload. Suppose that querying session C9F5E0A4B7D8F203 reveals that its target output port is port 2, and the load status of that port is obtained: bandwidth utilization 68%, queue depth 450 packets, and packet loss rate 0.02%.

[0061] When the current load of the target output port exceeds a preset load threshold, the session priority score and session status corresponding to the session identifier are retrieved from the chassis-level session table. If the session priority score is higher than the preset migration priority threshold and the session status is active, the adaptive hash weights corresponding to each output port are retrieved again. Output ports whose current load exceeds the preset load threshold are excluded. Among the remaining output ports, a new target output port is determined based on the adaptive hash weights. The output port mapping relationship between the session identifier and the new target output port is updated in the chassis-level session table, and a session migration notification is sent to the original target output port. If the session priority score is not higher than the preset migration priority threshold or the session status is inactive, the original target output port is retained. The preset load threshold is pre-configured based on port performance and service requirements, typically set to a bandwidth utilization range of 75%-85%. The threshold setting needs to balance port utilization and service quality; too low a threshold will lead to wasted port resources, while too high a threshold can easily cause congestion. In the current example, assuming the preset load threshold is 80% bandwidth utilization and a queue depth of no more than 1000 packets, since port 2's bandwidth utilization is 68%, which is below the 80% threshold, the port's load status is determined to be normal and does not exceed the threshold. At this time, the system directly uses port 2 as the destination for packet forwarding. When the load status of the target output port exceeds the preset threshold, the situation becomes more complex, and session migration needs to be considered. Suppose another session, D0A6F1B8C9E7F304, targets port 5. A query reveals that port 5's current bandwidth utilization has reached 92%, and the queue depth is 1280 packets, clearly exceeding the 80% load threshold, indicating that the port is already under high load or even overload. Continuing to forward packets to this port will exacerbate congestion, leading to increased latency or even packet loss. However, not all sessions are suitable for migration. Session migration itself introduces certain overhead and risks, including the synchronization of already transmitted packet states and the switching delay between the old and new ports. Therefore, the system needs to determine whether the session is worth migrating, based on the session's priority score and session state. The system further retrieves detailed information about session D0A6F1B8C9E7F304 from the chassis-level session table, including the session priority score and current session status. The session priority score is calculated and recorded in the session table when the packet is first processed; assuming this session has a priority score of 7.5, the session status field records that the session is active. Next, the session priority score is compared with a preset migration priority threshold, which is typically set between 6.0 and 7.0, indicating that only sufficiently important sessions are worth migrating, as migration consumes system resources and may introduce momentary service interruptions. Assuming the migration priority threshold is set to 6.5, and this session's score of 7.5 is higher than this threshold, and the session is active, both necessary conditions for migration are met.Once migration is confirmed, the system begins selecting a lighter-loaded output port for the session. The update operation needs to guarantee atomicity and consistency, typically achieved through database transactions or distributed lock mechanisms, ensuring that all components reading the session information see a consistent mapping. The session migration notification message informs the interface board that data packets for a specific session will no longer be sent to this port. If there are still backlogged data packets for this session in the output queue, special handling is required, such as sending them out as soon as possible or forwarding them to the new port. If the session priority score is not higher than the migration priority threshold, such as a regular web browsing session with a priority of only 4.2, migration will not be triggered even if its target port is heavily loaded, because the cost of migration may outweigh the importance of the session. These low-priority sessions can tolerate some latency or packet loss. Another scenario is when the session is inactive, such as a session that has not transmitted data packets for 15 seconds. Although its priority score is high, because it is inactive, it is likely about to end or enter the aging and deletion process. Migrating in this case is meaningless and wastes resources. For these sessions that do not meet the migration conditions, the system continues to use the original mapping, and data packets are still forwarded to the original target port.

[0062] The method for re-determining the new target output port based on the adaptive hash weight among the remaining output ports includes:

[0063] The adaptive hash weights of all remaining output ports are obtained, and the migration cost between the original target output port and each remaining output port is calculated. This migration cost is obtained by weighting the calculation based on the hop count, path bandwidth, and current path congestion level between the two output ports in the switching plane topology. Session migration sensitivity is calculated based on the number of transmitted data packets and session duration recorded in the chassis-level session table using the session identifier. When it is determined that a new output port needs to be selected for session migration, the port with the highest weight or lowest load is not simply chosen; multiple factors need to be considered to ensure the rationality of the migration decision. The adaptive hash weights of all remaining output ports are obtained, and the load level of each candidate port is recorded. Assume the weights of the remaining 5 output ports (1, 2, 3, 4, 6) are 0.18, 0.15, 0.20, 0.22, and 0.20, respectively. Migration cost is an important indicator for evaluating the feasibility of session migration; it quantifies the cost of switching data flow from the original port to the new port. The calculation of migration cost needs to consider the topology and real-time status of the switching plane within the chassis. First, there's the hop count factor, which refers to the path distance between the original target output port and the candidate new port. In a single-level switching architecture, any two ports are directly connected with a single hop, resulting in a hop count of 1. However, in multi-level or hierarchical switching architectures, the hop count between different port pairs may differ. Assume the hop counts between the original port 5 and each candidate port are: 2 hops to port 1, 1 hop to port 2, 1 hop to port 3, 2 hops to port 4, and 3 hops to port 6. A higher hop count means more switching nodes the data packet traverses during migration, leading to greater latency and higher migration costs. The second factor to consider is path bandwidth, which is the available bandwidth on the switching path from the original port to the new port. Even if the hop count is the same between two ports, insufficient bandwidth on the switching links along the path will affect the migration performance. The system maintains bandwidth monitoring information for each link in the switching plane. For example, the path from port 5 to port 3 may have a currently available bandwidth of 8 Gbps, while the path to port 2 may have an available bandwidth of 10 Gbps. The greater the available bandwidth, the faster the session data stream can be switched, and the lower the migration cost. Path congestion is the third factor, reflecting the traffic contention on the switching path. Even if a path has a high nominal bandwidth, congestion will occur if a large number of other sessions are also using this path, affecting the transmission quality after migration. The system assesses congestion by monitoring the queue length and packet loss rate of the switching links. For example, although the path from port 5 to port 4 has sufficient bandwidth, a current queue depth of 800 packets indicates severe congestion, with a congestion score of 0.7 (0 indicates no congestion, 1 indicates severe congestion). In contrast, the path from port 5 to port 1 has a queue depth of only 50 packets, with a congestion score of 0.1.Migration cost is calculated by combining these three factors using a weighted formula: Migration Cost = α × Hop Count + β × (1 / Path Bandwidth) + γ × Congestion Level, where α, β, and γ are weighting coefficients that can be adjusted according to actual network characteristics. We assume α = 0.4, β = 0.3, and γ = 0.3. Lower migration costs indicate easier migration implementation and less impact on the system. Besides migration cost, the session's own sensitivity to migration must also be considered. Some sessions are highly sensitive to path changes, such as real-time video streaming or VoIP calls; migration may lead to significant service interruptions or quality degradation. Other sessions, such as file downloads, have a higher tolerance for short migration processes. Session migration sensitivity is an indicator that quantifies this sensitivity. The calculation method is based on historical statistics recorded in the chassis-level session table. The number of transmitted data packets reflects the session's communication volume. For example, if session D0A6F1B8C9E7F304 has transmitted 5800 data packets, this is a fairly active session, indicating that its communication state has been stably established. Migration may disrupt this stable state, making it highly sensitive. The relationship between packet count and sensitivity can be represented by a piecewise function: new sessions with fewer than 100 packets have low sensitivity (0.2), established sessions with 100-1000 packets have medium sensitivity (0.5), and mature sessions with more than 1000 packets have high sensitivity (0.8). Session duration is another factor affecting sensitivity. The duration of the session from the first packet to the present is obtained from the session table, assumed to be 450 seconds. Long-duration sessions often establish complex application layer states, increasing the risk of migration. The sensitivity coefficient for sessions lasting more than 300 seconds can be set to 1.0, 0.7 for 100-300 seconds, and 0.4 for less than 100 seconds. Combining packet count and duration, the migration sensitivity of this session is calculated as: Migration Sensitivity = 0.6 × (Packet Count Factor) + 0.4 × (Duration Factor) = 0.88, indicating that this is a highly migration-sensitive session.

[0064] The migration suitability of each remaining output port is calculated by weighting its adaptive hash weight, migration cost, and session migration sensitivity. The remaining output port with the highest migration suitability is selected as the new target output port. Migration suitability is a comprehensive score that balances port load capacity, migration implementation difficulty, and session migration risk. The calculation formula is: Migration Suitability = w1 × Adaptive Hash Weight - w2 × Migration Cost - w3 × Migration Sensitivity, where w1, w2, and w3 are balancing coefficients, assumed to be w1=0.5, w2=0.3, and w3=0.2. Weighting terms contribute positively because high-weight ports with lighter loads are more suitable for receiving migrated traffic; migration cost and sensitivity contribute negatively because they increase the difficulty and risk of migration. This multi-factor comprehensive decision ensures that migration alleviates the load pressure on the original ports without causing excessive impact on the system due to the migration operation itself, while also considering the session characteristics' tolerance for migration, achieving optimal port reallocation.

[0065] The method of calculating session affinity based on session identifier and the load status of each chassis's output port, determining a chassis as the primary aggregation node based on the session affinity, and redirecting data packets with the same session identifier from other chassis to the corresponding output port of the primary aggregation node includes:

[0066] The system retrieves data packet distribution information for the same session identifier across chassis from the global session table, and counts the number of data packets belonging to the session identifier received by each chassis. Based on the number of data packets, it calculates the data packet carrying ratio for each chassis. It also obtains the output port load status for each chassis, including the current bandwidth utilization and data packet forwarding latency. In cross-chassis session traffic aggregation scenarios, the system needs to coordinate data packet forwarding across multiple chassis from a global perspective to ensure that homogeneous session traffic distributed across different chassis ultimately converges to a unified output point. When data packets for a specific session identifier are detected appearing in multiple chassis, the cross-chassis aggregation process is triggered. The system queries the global session table to determine the data packet distribution for that session identifier across chassis. For example, if session E1B7F2C8D9A6E405 is detected distributed across three chassis, the system extracts the distribution record for that session, which includes statistical information on the data packets received by each chassis. The specific query results show that chassis 1 has collected 2400 data packets for this session so far, chassis 2 has collected 1800 data packets, and chassis 3 has collected 800 data packets. These statistics are accumulated and reported by each chassis when synchronizing its local session table to the global session table. The update frequency is typically once per second, or an incremental report triggered after receiving a certain number of data packets, ensuring the data packet count in the global session table is relatively real-time and accurate. The carrying ratio is calculated based on the number of data packets from each chassis. This ratio reflects the contribution or correlation of each chassis to the session. The calculation method is to divide the number of data packets from that chassis by the total number of data packets from all chassis. In the current example, the total number of data packets is 2400 + 1800 + 800 = 5000. Therefore: Chassis 1's carrying ratio = 2400 / 5000 = 0.48 (48%), Chassis 2's carrying ratio = 1800 / 5000 = 0.36 (36%), and Chassis 3's carrying ratio = 800 / 5000 = 0.16 (16%). The higher this ratio, the closer the connection between that chassis and the session, and the more session traffic passes through that chassis. From the perspective of proximity and reducing cross-chassis forwarding overhead, this chassis is more suitable as the primary aggregation node. Next, we obtain the load status information of each chassis's output ports. Here, "output port" specifically refers to the port used to output aggregated data to the backend analysis system; each chassis typically has several such output ports. Load status includes two key indicators: current bandwidth utilization and packet forwarding latency. Bandwidth utilization is obtained by monitoring the ratio of the port's actual transmission rate to its rated rate. For example, the rated rate of the output port in chassis 1 is 10Gbps, and the current transmission rate is 4.5Gbps, so the bandwidth utilization = 4.5 / 10 = 0.45, or 45%. Packet forwarding latency refers to the average waiting time for a data packet from entering the output queue to its actual transmission, reflecting the port's congestion level and processing efficiency. The current forwarding latency for chassis 1 is 1.2 milliseconds.Similarly, chassis 2 had a bandwidth utilization of 62% and a forwarding latency of 2.8 milliseconds, while chassis 3 had a bandwidth utilization of 38% and a forwarding latency of 0.9 milliseconds.

[0067] The session affinity of each chassis is calculated based on the data packet carrying ratio and the output port load status. Session affinity characterizes the strength of the association between the chassis and the session. The chassis with the highest session affinity is selected as the primary aggregation node. When multiple chassis have the same highest session affinity, the chassis carrying the most session data packets is selected as the primary aggregation node. In the current case, chassis 1 has the highest affinity of 0.52, therefore it is selected as the primary aggregation node. A special case is also considered: when multiple chassis have very close or even identical session affinity, a clear selection rule is needed to break the tie. Assuming that the session affinity of chassis 1 and 2 is both 0.50, the rule used is to select the chassis carrying the most session data packets. Since chassis 1 carries 2400 data packets, more than chassis 2's 1800, chassis 1 will be prioritized even if the affinity is the same. This rule is based on the consideration that the chassis carrying more data packets has already handled most of the traffic for the session, and the cross-chassis forwarding overhead caused by aggregation is minimized there.

[0068] After determining the primary aggregation node, a redirection command is sent to other chassis. This redirection command includes a session identifier, the primary aggregation node identifier, and the target output port information. Upon receiving the redirection command, other chassis query their local chassis-level session table and identify data packets belonging to the specified session identifier. They then forward subsequently received data packets with the same session identifier to the primary aggregation node via the cross-chassis link. The primary aggregation node receives the data packets forwarded from other chassis, merges them with data packets with the same session identifier collected by its own chassis, and outputs them through the same output port. After determining chassis number 1 as the primary aggregation node, the system needs to notify other chassis to redirect traffic. The centralized controller or coordinating node constructs a redirection command, a structured control message containing multiple information fields: The session identifier field, filled with E1B7F2C8D9A6E405, identifies which session the redirection command targets; the main aggregator node identifier field is filled with the unique number or network address of chassis 1; the target output port information field specifies which specific port on chassis 1 is used to output the aggregated traffic for this session, such as chassis 1 - output port 4; additionally, it may include auxiliary information such as an effective timestamp, command sequence number, and verification signature. The redirection command is sent through the inter-chassis control channel, which is typically a dedicated network independent of the data forwarding channel, employing a reliable transmission protocol to ensure no control message loss. The redirection command is sent to all relevant chassis except the main aggregator node. Upon receiving the redirection command, the chassis parses it, extracts the session identifier E1B7F2C8D9A6E405, and then queries its chassis-level session table to search for the record corresponding to that session identifier. After locating the record, the session is marked as cross-chassis forwarding, and redirection target information is added to the record, namely, the target chassis is 1 and the target port is output port 4 of chassis 1. Data packets for this session already waiting to be sent in the local chassis output queue are redirected to the main aggregation node. The processing logic of chassis 1 needs to process both locally collected data packets and data packets forwarded from other chassis. When chassis 1 receives a data packet from the cross-chassis link, it first parses the encapsulation header to identify that this is redirected traffic from session E1B7F2C8D9A6E405, with the target being output port 4 of its own chassis. Then, the cross-chassis transmission encapsulation header is removed from the data packet, restoring it to its original data packet format, and it is mixed with data packets from the same session collected locally within the same chassis. This mixing process takes place in the input buffer of output port 4. Data packets from different sources (local collection and remote forwarding) are placed in the same queue and sorted according to arrival timestamps or packet sequence numbers to ensure that the relative order of data packets is maintained as much as possible. Ultimately, all data packets belonging to session E1B7F2C8D9A6E405, regardless of which chassis they were initially collected from, converge at output port 4 of chassis 1, and are sent to the backend analysis system from this single exit point.The backend system receives a complete and unified session data stream, without any trace of the data packets being scattered across multiple chassis, thus achieving transparent aggregation across chassis.

[0069] The method for calculating the session affinity of each chassis based on the data packet carrying ratio and the output port load status includes:

[0070] The bandwidth load factor is calculated by comparing the current bandwidth utilization rate of each chassis's output port with a preset bandwidth baseline value, and the delay load factor is calculated by comparing the packet forwarding delay with a preset delay baseline value. The output port load factor is then calculated based on these two factors. The bandwidth load factor is calculated using a normalization method, comparing the current bandwidth utilization rate with the preset bandwidth baseline value. The preset bandwidth baseline value represents the expected load level of the output port under normal operating conditions, typically set to 60%-70% of the port capacity. At this load level, the port maintains high utilization without congestion. Assuming a preset bandwidth baseline value of 0.65 (65%), for chassis 1's output port with a current bandwidth utilization rate of 45%, the bandwidth load factor is approximately 0.69. A value less than 1 indicates that the port load is below the baseline, leaving some margin. The delay baseline value is an acceptable delay level set based on the port type and expected performance. For example, for a 10Gbps high-speed port, a delay baseline value of 1.5 milliseconds can be set. Chassis 1 has a forwarding latency of 1.2 milliseconds, and a latency load factor of 1.2 / 1.5 = 0.80, indicating that the latency is within an acceptable range. The output port load factor reflects the overall load level and output capacity of the port. The calculation formula is: Output Port Load Factor = 0.6 × Bandwidth Load Factor + 0.4 × Latency Load Factor, where the coefficients 0.6 and 0.4 indicate that bandwidth utilization has a slightly higher weight than latency, as bandwidth is a more direct measure of load. A smaller load factor indicates a lighter port load, stronger output capacity, and greater suitability for handling more aggregated traffic.

[0071] The session priority score corresponding to the session identifier is obtained from the global session table. Based on the session priority score, the packet carrying ratio weight coefficient and the output port load comprehensive factor weight coefficient are determined. The carrying weight value is calculated based on the packet carrying ratio and its corresponding weight coefficient, and the load weight value is calculated based on the output port load comprehensive factor and its corresponding weight coefficient. The original session affinity value for each chassis is calculated based on the carrying weight value and the load weight value. The original session affinity values ​​for all chassis are normalized to obtain the session affinity for each chassis. The priority score of session E1B7F2C8D9A6E405 is obtained from the global session table, assumed to be 7.2. For high-priority sessions, more attention should be paid to the load status of the output port to ensure the selection of ports with light load and good performance, guaranteeing service quality. For low-priority sessions, more consideration can be given to the carrying ratio, aggregating nearby ports to reduce cross-chassis transmission overhead. The weight coefficients are determined using a piecewise linear or non-linear mapping function. The priority score (0-10) is used as input, and the output is the carrying ratio weight coefficient and the load factor weight coefficient, the sum of which is 1. For example, the mapping rule is: for priority 0-4, the load ratio weight is 0.7 and the load factor weight is 0.3, tending to aggregate the nearest node; for priority 4-7, the two weights gradually approach each other, reaching 0.5 at priority 7; for priority 7-10, the load ratio weight drops to 0.3 and the load factor weight rises to 0.7, prioritizing performance. For the current priority 7.2 session, linear interpolation is used to calculate: the load ratio weight coefficient is approximately 0.487, and the load factor weight coefficient is approximately 0.513. With the weight coefficients, the load weight value and load weight value are calculated separately. Load weight value = packet load ratio × load ratio weight coefficient, reflecting the combined effect of the chassis's data capacity and the weight coefficient. When calculating the load weight value, it's important to note that a smaller output port load factor is better (indicating a light load), but in weight value calculation, this should be converted to a positive indicator, i.e., a light load corresponds to a high weight value. One approach is to take the reciprocal or subtract the load factor from a constant: Load weight value = (2 - output port load factor) × load factor weight coefficient. The raw session affinity value is obtained by adding the bearer weight value and the load weight value, reflecting the absolute affinity of each chassis. However, for ease of comparison and interpretation, it is usually normalized. The normalized affinity value is between 0 and 1, and the sum is 1, which more intuitively shows the relative importance of each chassis. This achieves a dynamic balance between packet distribution and port performance, ensuring that the selection of the main aggregation node is both reasonable and efficient.

[0072] The method for calculating the adaptive aging time based on the data packet arrival time interval and session activity, and deleting the session from the session table when the session idle time exceeds the adaptive aging time, includes:

[0073] The session table records the most recent data packet arrival timestamp for each session identifier. When a new data packet belonging to that session identifier is received, the data packet arrival time interval is calculated based on the new data packet arrival timestamp and the most recent data packet arrival timestamp. This data packet arrival time interval is stored in the time interval history record of the corresponding session identifier in the session table. The session aging mechanism is crucial for maintaining the health of the session table and the effective utilization of system resources. The session table maintains a set of time statistics for each session identifier, the most basic of which is the most recent data packet arrival timestamp. This timestamp precisely records the moment when the last data packet of the session was collected or forwarded, using a high-precision time format. When the system receives a new data packet and identifies its session identifier as F2C8D9A7E0B5F506, it obtains the current precise timestamp as the new data packet arrival timestamp. Then, it queries the session table to read the most recent data packet arrival timestamp recorded for that session identifier. The data packet arrival time interval characterizes the current communication frequency of the session; a short interval indicates dense communication, while a long interval indicates sparse communication. The calculated time interval value is stored in the time interval history record corresponding to that session identifier in the session table. This history record uses a sliding window structure, storing the N most recent time interval values. For example, N=50, meaning it retains the time intervals between the arrival of the last 50 data packets. When a new interval value is added, if the history record is full, the oldest interval value is deleted, maintaining a constant record length. This sliding window design reflects the short-term communication patterns of a session without consuming excessive storage space due to storing too much historical data. For newly established sessions, the history record is gradually filled from empty until the window size is reached.

[0074] The process involves calculating the mean and variance of the arrival time intervals of each data packet in the historical time interval record, and then calculating the time interval stability coefficient based on these values. Session activity is calculated based on the total number of data packets received by the session identifier and the data packet arrival time intervals. The session priority score corresponding to the session identifier is retrieved from the session table, and an aging time baseline and adjustment coefficient are determined based on the session priority score. An initial aging time is calculated based on the aging time baseline, time interval stability coefficient, and adjustment coefficient. An adaptive aging time for the session identifier is then calculated based on the initial aging time and session activity. The time difference between the current timestamp and the most recent data packet arrival timestamp of the session identifier is monitored in real time as the session idle time. When the session idle time exceeds the adaptive aging time, the session record corresponding to the session identifier is deleted from the local session table, chassis-level session table, or global session table, and related resources are released. The mean reflects the average frequency of data packet arrivals. For example, if the mean of 50 historical intervals for a session is 180 milliseconds, it means that a data packet arrives on average every 180 milliseconds. The variance reflects the degree of fluctuation in the time interval; for example, a variance of 25 milliseconds... 2 This indicates that the arrival time of data packets is relatively stable; if the variance is large, for example, 8100 milliseconds... 2 This indicates that the time interval fluctuates drastically, sometimes a data packet arrives in tens of milliseconds, and sometimes in hundreds of milliseconds. The time interval stability coefficient is a quantitative indicator calculated based on the mean and variance. For example, the time interval stability coefficient = mean / standard deviation, where the standard deviation is the square root of the variance. For the aforementioned mean of 180 milliseconds and variance of 25 milliseconds... 2 For a given session, with a standard deviation of 5 milliseconds and a stability coefficient of 180 / 5 = 36, a large value indicates high stability. This is for a session with a mean of 180 milliseconds and a variance of 8100 milliseconds. 2For a given session, the standard deviation is 90 milliseconds, and the stability coefficient is 180 / 90 = 2. A smaller value indicates instability. To avoid the stability coefficient being too large or too small, it can be normalized or logarithmized, thus limiting the coefficient value to between 0 and 1; the closer to 1, the more stable the session. Session activity is another important evaluation dimension, which comprehensively considers the number of data packets and communication frequency. The total number of data packets received since the session identifier was established is obtained from the session table, assumed to be 8500. Combined with the data packet arrival time interval, the data packet rate per unit time can be calculated. If the average time interval is 180 milliseconds (0.18 seconds), then the data packet rate is approximately 5.56 packets / second. Session activity can be defined as a function of the data packet rate, for example: Session Activity = min(Data Packet Rate / Baseline Rate, 1.0), where the baseline rate is set to a reference value such as 10 packets / second, and the activity is limited to between 0 and 1. The current session's activity = 5.56 / 10 = 0.556, indicating a moderate level of activity. The initial aging time is calculated as follows: Aging time baseline value × Time interval stability coefficient weight × Adjustment coefficient. The final adaptive aging time is further adjusted based on session activity: Adaptive aging time = Initial aging time × (1 + Session activity). Sessions with higher activity are given longer aging times because they are more likely to resume communication after brief transmission pauses. The adaptive aging time reflects both the session's priority and importance, as well as its actual communication pattern and activity level, achieving true adaptability. When idle time continues to grow beyond the adaptive aging time, an aging deletion operation is triggered. The system deletes all records corresponding to the session identifier from the local session table, chassis-level session table, and global session table, including the session identifier, five-tuple information, priority score, statistics, output port mapping relationships, etc. Simultaneously, it releases the relevant resources allocated to the session, such as cache space in the output port queue, entries in the forwarding cache, and memory occupied by the monitoring process. The aging deletion operation ensures that the session table does not grow indefinitely, promptly reclaiming resources occupied by inactive sessions and freeing up space for new sessions.

[0075] The method for determining the aging time baseline and adjustment coefficient based on the session priority score includes:

[0076] The system compares the session priority score with multiple preset priority score thresholds to determine the priority level corresponding to the session identifier. Based on the priority level, it retrieves the corresponding aging time baseline value from a preset aging time baseline value mapping table. It then obtains the session duration and the number of transmitted data packets corresponding to the session identifier from the session table. The system compares the session duration with a preset duration threshold to obtain a duration impact factor, and compares the number of transmitted data packets with a preset data packet number threshold to obtain a data volume impact factor. Based on the duration impact factor and the data volume impact factor, it calculates a session state comprehensive factor. Finally, it performs a weighted calculation based on the priority level and the session state comprehensive factor to obtain an adjustment coefficient. The system presets multiple priority score thresholds, which divide different priority level ranges. This hierarchical mechanism discretizes the continuous score space into a finite number of levels, providing a buffer and preventing drastic changes in the aging strategy due to small fluctuations in priority scores. The aging time baseline value mapping table is a pre-configured data structure, which can be a simple array or a hash table, storing the aging time baseline value corresponding to each priority level. The mapping relationship is designed based on business needs and experience data; high-priority sessions require longer retention times, while low-priority sessions can age faster. An example mapping table is as follows: Level 1 corresponds to a baseline value of 15 seconds, Level 2 to 35 seconds, Level 3 to 65 seconds, and Level 4 to 130 seconds. A query reveals that the aging time baseline value for Level 3 high priority is 65 seconds. The session duration is extracted from the session table; this is the total duration from session establishment (the arrival of the first data packet) to the current moment. The preset duration threshold is set according to business characteristics, for example, 600 seconds (10 minutes). If the session duration exceeds the threshold, it indicates a long-lived session that may be carrying continuous business and should be given a more lenient aging strategy; conversely, it may be a short-term, temporary session. The duration impact factor is calculated using a piecewise linear function. When the duration is less than half the threshold (300 seconds), the duration impact factor is 0.8, indicating that short-term sessions can age faster. When the duration is between half and the threshold (300-600 seconds), the duration impact factor is 1.0, indicating that medium-life sessions use the standard strategy. When the duration exceeds the threshold (>600 seconds), the duration impact factor is 1.0 + (duration - 600) / 600, with a maximum of 1.5. For the current 886-second session, the duration impact factor is 1.477, indicating that its aging time should be extended. The number of transmitted data packets is obtained from the statistics field of the session table, assumed to be 12,500 packets. This is compared with a preset data packet count threshold, set at 5,000 packets, representing a meaningful data transmission volume.The data volume impact factor is also calculated using a piecewise function: when the number of data packets is less than half the threshold (2500), the data volume impact factor is 0.9; when it is between half and the threshold (2500-5000), the impact factor is 1.0; when it exceeds the threshold, the data volume impact factor is 1.0 + log10(number of data packets / 5000), with a maximum of 1.6. Currently, with 12500 packets, the data volume impact factor is 1.398. The session state comprehensive factor combines the effects of both duration and data volume: Session state comprehensive factor = (duration impact factor + data volume impact factor) / 2. An arithmetic average is used to ensure the factor remains within a reasonable range. The current session's comprehensive factor is 1.4375, reflecting the session's importance in the system. A larger factor indicates a more important session, deserving more resource investment and a longer retention time. Different priority levels have different sensitivities to the state comprehensive factor; higher priority levels are more sensitive to the state factor, meaning changes in the state factor have a greater impact on the adjustment coefficient. The calculation formula is: Adjustment coefficient = Priority level base coefficient × Session state comprehensive factor ^ Level sensitivity index. Wherein, the priority level base coefficient is a fixed coefficient for each level: Level 1 is 0.8, Level 2 is 1.0, Level 3 is 1.2, and Level 4 is 1.5; the level sensitivity index controls the influence of the state factor: Level 1 is 0.5, Level 2 is 0.7, Level 3 is 0.9, and Level 4 is 1.0. An adjustment coefficient greater than 1 indicates that the aging time needs to be extended, while a coefficient less than 1 indicates that the aging time can be shortened.

[0077] Example 2: Based on the same inventive concept, such as Figure 2 As shown, this embodiment also provides a multi-level homogeneous session traffic aggregation system, the system including: a data packet acquisition and session identifier generation module, a first aggregation level processing module, a second aggregation level processing module, a third aggregation level processing module, and a session integrity report generation module, with each module connected in sequence.

[0078] The packet acquisition and session identifier generation module is used to acquire network traffic from different links through multiple service interface boards to obtain several data packets; extract the five-tuple information of each data packet; extract data packet features in the edge computing unit of each service interface board; calculate the session feature vector based on the five-tuple information and data packet features; calculate the session priority score based on the session feature vector; generate a session identifier based on the five-tuple information; and mark data packets with the same five-tuple information as same-source session traffic.

[0079] The first aggregation level processing module is used to establish a local session table for each service interface board at the first aggregation level. The local session table records session identifier, five-tuple information, session priority score and session status. Data packets of high-priority sessions are aggregated first according to the session priority score.

[0080] The second aggregation level processing module is used to synchronize the local session table to the chassis-level session table of each service interface board at the second aggregation level; dynamically adjust the adaptive hash weight according to the load status of each output port; and forward data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight.

[0081] The third aggregation level processing module is used to synchronize the chassis-level session table to the global session table in the third aggregation level; for cross-chassis same-source session traffic, it calculates session affinity based on session identifier and the output port load status of each chassis, determines a chassis as the main aggregation node based on the session affinity, and redirects data packets with the same session identifier on other chassis to the corresponding output port of the main aggregation node.

[0082] The session integrity report generation module is used to calculate the adaptive aging time based on the data packet arrival time interval and session activity. When the session idle time exceeds the adaptive aging time, the session is deleted from the session table. All data packets belonging to the same session identifier are output from the same output port to the backend analysis system, and a session integrity report is generated.

[0083] It should be noted that the specific methods by which each module performs operations in the system described in the above embodiments have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0084] Finally, it should be noted that although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for multi-level same-source session traffic aggregation, characterized in that, The method includes: Network traffic from different links is collected through multiple service interface boards to obtain several data packets; the five-tuple information of each data packet is extracted; data packet features are extracted in the edge computing unit of each service interface board, and a session feature vector is calculated based on the five-tuple information and data packet features; a session priority score is calculated based on the session feature vector; a session identifier is generated based on the five-tuple information, and data packets with the same five-tuple information are marked as same-source session traffic; At the first aggregation level, each service interface board establishes a local session table, which records session identifiers, five-tuple information, session priority scores, and session status; based on the session priority scores, data packets from high-priority sessions are aggregated first. At the second aggregation level, each service interface board synchronizes the local session table to the chassis-level session table; dynamically adjusts the adaptive hash weight according to the load status of each output port; and forwards data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight. At the third aggregation level, each chassis synchronizes its chassis-level session table to the global session table. For cross-chassis same-source session traffic, session affinity is calculated based on the session identifier and the output port load status of each chassis. Based on the session affinity, a chassis is determined as the main aggregation node, and data packets with the same session identifier on other chassis are redirected to the corresponding output port of the main aggregation node. The adaptive aging time is calculated based on the data packet arrival time interval and session activity. When the session idle time exceeds the adaptive aging time, the session is deleted from the session table. All data packets belonging to the same session identifier are output from the same output port to the backend analysis system, and a session integrity report is generated.

2. The method for multi-level same-source session traffic aggregation according to claim 1, characterized in that, The method of forwarding data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight includes: After each service interface board receives a data packet and generates a session identifier, it queries the chassis-level session table to determine whether the session identifier already has an output port mapping relationship. If the session identifier does not have an output port mapping relationship, it obtains the adaptive hash weight corresponding to each output port, performs a hash operation on the five-tuple information of the session identifier to obtain a hash value, divides the hash value space into multiple weight intervals according to the adaptive hash weight of each output port, determines the target output port according to the weight interval in which the hash value falls, and establishes an output port mapping relationship between the session identifier and the target output port in the chassis-level session table. If the session identifier already has an output port mapping relationship, it retrieves the target output port corresponding to the session identifier from the chassis-level session table. The service interface board calculates the forwarding path through the switching plane based on the target output port; encapsulates the data packet with a forwarding instruction, which includes a session identifier, a target output port identifier, and forwarding path information; and sends the data packet and forwarding instruction to the service interface board where the target output port is located through the switching plane; the service interface board where the target output port is located parses the forwarding instruction and verifies the consistency of the mapping relationship between the session identifier and the output port; and uses the same output port mapping relationship and forwarding path for subsequent data packets with the same session identifier.

3. The method for multi-level same-source session traffic aggregation according to claim 2, characterized in that, The method for obtaining the target output port corresponding to the session identifier from the chassis-level session table includes: The target output port corresponding to the session identifier and the current load status of the target output port are obtained from the chassis-level session table; when the current load status of the target output port does not exceed the preset load threshold, the target output port is directly used as the forwarding destination of the data packet; When the current load of the target output port exceeds a preset load threshold, the session priority score and session status corresponding to the session identifier are obtained from the chassis-level session table. When the session priority score is higher than the preset migration priority threshold and the session status is active, the adaptive hash weights corresponding to each output port are re-obtained, output ports whose current load exceeds the preset load threshold are excluded, and a new target output port is re-determined from the remaining output ports according to the adaptive hash weights. The output port mapping relationship between the session identifier and the new target output port is updated in the chassis-level session table, and a session migration notification is sent to the original target output port. When the session priority score is not higher than the preset migration priority threshold or the session status is inactive, the original target output port is retained.

4. The method for multi-level same-source session traffic aggregation according to claim 3, characterized in that, The method for re-determining the new target output port based on the adaptive hash weight among the remaining output ports includes: Obtain the adaptive hash weights of all remaining output ports, calculate the migration cost between the original target output port and each remaining output port, and calculate the migration cost by weighting the number of hops, path bandwidth and current path congestion level between two output ports in the switching plane topology; calculate the session migration sensitivity based on the number of transmitted data packets and session duration recorded in the chassis-level session table with the session identifier. The migration adaptability of each remaining output port is calculated by weighting the adaptive hash weight, migration cost, and session migration sensitivity. The remaining output port with the highest migration adaptability is selected as the new target output port.

5. The method for multi-level same-source session traffic aggregation according to claim 1, characterized in that, The method of calculating session affinity based on session identifier and the load status of each chassis's output port, determining a chassis as the primary aggregation node based on the session affinity, and redirecting data packets with the same session identifier from other chassis to the corresponding output port of the primary aggregation node includes: Retrieve data packet distribution information for the same session identifier across all chassis from the global session table, and count the number of data packets belonging to the session identifier received by each chassis; calculate the data packet carrying ratio of each chassis based on the number of data packets; obtain the output port load status of each chassis, including the current bandwidth utilization and data packet forwarding delay of the output port; The session affinity of each chassis is calculated based on the data packet carrying ratio and the output port load status. The session affinity characterizes the association strength between the chassis and the session. The chassis with the highest session affinity is selected as the main aggregation node. When multiple chassis have the same highest session affinity, the chassis carrying the most session data packets is selected as the main aggregation node. After determining the primary aggregation node, a redirection command is sent to other chassis. The redirection command includes a session identifier, a primary aggregation node identifier, and target output port information. Upon receiving the redirection command, other chassis query their local chassis-level session table and identify data packets belonging to the session identifier. They then forward subsequently received data packets with the session identifier to the primary aggregation node via cross-chassis links. After receiving data packets forwarded from other chassis, the primary aggregation node merges them with data packets with the same session identifier collected by its own chassis and outputs them through the same output port.

6. The multi-level same-source session traffic aggregation method according to claim 5, characterized in that, The method for calculating the session affinity of each chassis based on the data packet carrying ratio and the output port load status includes: The ratio of the current bandwidth utilization rate of each chassis's output port to a preset bandwidth baseline value is used as the bandwidth load factor, and the ratio of the packet forwarding delay to a preset delay baseline value is used as the delay load factor; the output port load comprehensive factor is calculated based on the bandwidth load factor and the delay load factor. The session priority score corresponding to the session identifier is obtained from the global session table. The packet carrying ratio weight coefficient and the output port load comprehensive factor weight coefficient are determined based on the session priority score. The carrying weight value is calculated based on the packet carrying ratio and its corresponding weight coefficient. The load weight value is calculated based on the output port load comprehensive factor and its corresponding weight coefficient. The original session affinity value of each chassis is calculated based on the carrying weight value and the load weight value. The original session affinity values ​​of all chassis are normalized to obtain the session affinity of each chassis.

7. The method for multi-level same-source session traffic aggregation according to claim 1, characterized in that, The method for calculating the adaptive aging time based on the data packet arrival time interval and session activity, and deleting the session from the session table when the session idle time exceeds the adaptive aging time, includes: In the session table, the most recent data packet arrival timestamp is recorded for each session identifier. When a new data packet belonging to the session identifier is received, the data packet arrival time interval is calculated based on the arrival timestamp of the new data packet and the most recent data packet arrival timestamp. The data packet arrival time interval is then stored in the time interval history record of the corresponding session identifier in the session table. The mean and variance of the arrival time intervals of each data packet in the time interval history are calculated, and the time interval stability coefficient is calculated based on the mean and variance of the arrival time intervals. The session activity is calculated based on the total number of data packets received by the session identifier and the data packet arrival time intervals. The session priority score corresponding to the session identifier is obtained from the session table, and the aging time base value and adjustment coefficient are determined based on the session priority score. The initial aging time is calculated based on the aging time base value, the time interval stability coefficient, and the adjustment coefficient. The adaptive aging time of the session identifier is calculated based on the initial aging time and the session activity. The time difference between the current timestamp and the most recent data packet arrival timestamp of the session identifier is monitored in real time as the session idle time. When the session idle time exceeds the adaptive aging time, the session record corresponding to the session identifier is deleted from the local session table, the chassis-level session table, or the global session table, and the relevant resources are released.

8. The method for multi-level same-source session traffic aggregation according to claim 7, characterized in that, The method for determining the aging time baseline and adjustment coefficient based on the session priority score includes: The session priority score is compared with multiple preset priority score thresholds to determine the priority level corresponding to the session identifier; the corresponding aging time base value is retrieved from a preset aging time base value mapping table according to the priority level; the session duration and the number of transmitted data packets corresponding to the session identifier are obtained from the session table; the session duration is compared with a preset duration threshold to obtain a duration impact factor, and the number of transmitted data packets is compared with a preset data packet number threshold to obtain a data volume impact factor; a session state comprehensive factor is calculated based on the duration impact factor and the data volume impact factor; and an adjustment coefficient is obtained by weighting the priority level and the session state comprehensive factor.

9. A multi-level homogeneous session traffic aggregation system, characterized in that, The system includes: a data packet acquisition and session identifier generation module, a first aggregation level processing module, a second aggregation level processing module, a third aggregation level processing module, and a session integrity report generation module, with each module communicating with each other in sequence; The packet acquisition and session identifier generation module is used to acquire network traffic from different links through multiple service interface boards to obtain several data packets; extract the five-tuple information of each data packet; extract data packet features in the edge computing unit of each service interface board; calculate a session feature vector based on the five-tuple information and data packet features; calculate a session priority score based on the session feature vector; generate a session identifier based on the five-tuple information; and mark data packets with the same five-tuple information as same-source session traffic. The first aggregation level processing module is used to establish a local session table for each service interface board at the first aggregation level. The local session table records session identifier, five-tuple information, session priority score and session status. Data packets of high-priority sessions are aggregated first according to the session priority score. The second aggregation level processing module is used to synchronize the local session table of each service interface board to the chassis-level session table at the second aggregation level; dynamically adjust the adaptive hash weight according to the load status of each output port; and forward data packets with the same session identifier to the same output port through the switching plane according to the adaptive hash weight. The third aggregation level processing module is used to synchronize the chassis-level session table to the global session table in the third aggregation level; for cross-chassis same-source session traffic, it calculates session affinity based on session identifier and output port load status of each chassis, determines a chassis as the main aggregation node based on the session affinity, and redirects data packets with the same session identifier on other chassis to the corresponding output port of the main aggregation node. The session integrity report generation module is used to calculate the adaptive aging time based on the data packet arrival time interval and session activity. When the session idle time exceeds the adaptive aging time, the session is deleted from the session table. All data packets belonging to the same session identifier are output from the same output port to the backend analysis system, and a session integrity report is generated.

Images