Enhanced processing for IPSEC flows

Abstract

Embodiments of the present disclosure relate to methods, apparatuses, and computer readable storage media for processing Internet Protocol Security (IPsec) flows. One method includes determining a security association for an incoming flow, the incoming flow comprising a plurality of packets; performing pre-processing on the plurality of packets based on the security association; and in response to performing the pre-processing on at least one packet of the plurality of packets, performing parallel processing on the at least one packet of the plurality of packets.

Description

Technical Field

[0001] Embodiments of this disclosure generally relate to the telecommunications field, and in particular to apparatus, methods, and computer-readable storage media for processing Internet Protocol Security (IPsec) streams. Background Technology

[0002] IPsec is a suite of secure network protocols that authenticates and encrypts data packets to provide secure, encrypted communication between two entities over Internet Protocol (IP) networks. IPsec can be used to create site-to-site IPsec tunnels. According to the technical specifications of the 3rd Generation Partnership Project (3GPP), Base Transceiver Stations (BTSs) and Service Gateways (S-GWs) transmit user plane data packets through IPsec tunnels. The IPsec standard is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 4301, RFC 4303, and their series of RFCs. To support the high throughput of 5G communication systems, such as the required throughput of tens of Gbps, transmitting data packets through IPsec tunnels should be efficient and optimized according to the standard. Summary of the Invention

[0003] Generally, exemplary embodiments of this disclosure provide apparatus, methods, and computer-readable storage media for processing IPsec streams.

[0004] In a first aspect, an apparatus is provided. The apparatus includes at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to determine a security association for an incoming stream, the incoming stream including a plurality of packets; perform preprocessing on the plurality of packets based on the security association; and, in response to performing preprocessing on at least one of the plurality of packets, perform parallel processing on at least one of the plurality of packets.

[0005] In a second aspect, a method is provided. The method includes determining a security association for an incoming stream, the incoming stream comprising multiple packets; performing preprocessing on the multiple packets based on the security association; and performing parallel processing on at least one of the multiple packets in response to performing preprocessing on at least one of the multiple packets.

[0006] In a third aspect, an apparatus is provided, comprising: means for determining a security association for an incoming stream, the incoming stream including a plurality of packets; means for performing preprocessing on the plurality of packets based on the security association; and means for performing parallel processing on at least one of the plurality of packets in response to performing preprocessing on at least one of the plurality of packets.

[0007] In a fourth aspect, a non-transitory computer-readable medium is provided, comprising program instructions for causing a device to at least execute the method according to the second aspect above.

[0008] It should be understood that the summary portion is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] The above and other objects, features, and advantages of this disclosure will become more apparent from a more detailed description of some exemplary embodiments of the present disclosure illustrated in the accompanying drawings, wherein:

[0010] Figure 1 A block diagram is shown illustrating an example environment in which some example embodiments of the present disclosure may be implemented;

[0011] Figure 2A A flowchart illustrating an example process for handling IPsec streams in an encrypted context is shown.

[0012] Figure 2B A flowchart illustrating an example process for handling IPsec streams in a decrypted context is shown.

[0013] Figure 3 A block diagram of a hierarchical approach for processing IPsec flows is shown;

[0014] Figure 4 A simplified block diagram of an apparatus for processing IPsec streams according to some example embodiments of the present disclosure is shown;

[0015] Figure 5 A flowchart is shown, illustrating an example method for processing IPsec flows according to some example embodiments of this disclosure;

[0016] Figure 6 A flowchart is shown illustrating an example method for determining security associations according to some example embodiments of this disclosure;

[0017] Figure 7A A block diagram illustrating the processing flow of packets for a new IPsec flow according to some example embodiments of the present disclosure is shown;

[0018] Figure 7B A block diagram illustrating the processing flow of packets in a preprocessed IPsec stream according to some example embodiments of the present disclosure is shown;

[0019] Figure 7C A block diagram illustrating a processing flow for packets of new non-IPsec flows according to some example embodiments of the present disclosure is shown;

[0020] Figure 7DA block diagram illustrating a processing flow for packets of preprocessed non-IPsec streams according to some example embodiments of the present disclosure is shown;

[0021] Figure 8 A graph showing the throughput during sequence number generation is displayed;

[0022] Figure 9 A simplified block diagram of a device suitable for implementing embodiments of the present disclosure is shown; and

[0023] Figure 10 A block diagram of an example computer-readable medium according to some example embodiments of the present disclosure is shown.

[0024] In all the accompanying drawings, the same or similar reference numerals represent the same or similar elements. Detailed Implementation

[0025] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only and to assist those skilled in the art in understanding and implementing this disclosure, and are not intended to limit the scope of this disclosure in any way. The disclosure described herein may be practiced in various ways other than those described below.

[0026] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0027] References to "one embodiment," "embodiment," "an example embodiment," etc., in this disclosure indicate that the described embodiment may include specific features, structures, or characteristics, but not every embodiment necessarily includes specific features, structures, or characteristics. Furthermore, these phrases do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in conjunction with an example embodiment, whether explicitly described or not, those skilled in the art will understand that such feature, structure, or characteristic is affected by other embodiments.

[0028] It should be understood that although the terms “first” and “second” may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0029] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. As used herein, unless the context clearly indicates otherwise, the singular forms “a / an” and “the” are also intended to include the plural forms. It will be further understood that the terms “comprises,” “comprising,” “has,” “having,” “includes,” and / or “including,” as used herein, specify the presence of the stated features, elements, and / or components, but do not preclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0030] The term "circuitry" as used in this application may refer to one or more or all of the following:

[0031] (a) Hardware circuit implementations only (such as implementations only in analog and / or digital circuit systems), and

[0032] (b) A combination of hardware circuitry and software, such as (if applicable):

[0033] (i) A combination of analog and / or digital hardware circuitry (one or more) and software / firmware, and

[0034] (ii) Any part having software (including one or more hardware processors, including digital signal processors, software, and memory, which work together to enable a device (such as a mobile phone or server) to perform various functions), and

[0035] (c) Hardware circuitry (one or more) and / or processors (one or more), such as microprocessors (one or more) or a portion thereof, which require software (e.g. firmware) to operate, but may be absent when no software is required to operate.

[0036] This definition of circuit system applies to all uses of the term in this application, including in any claim. As a further example, as used in this application, the term circuit system also covers implementations of hardware circuitry or processors (or processors) or portions thereof and their accompanying software and / or firmware. The term circuit system also covers, for example, and if applicable to elements of a particular claim, baseband integrated circuits or processor integrated circuits in mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or networking devices.

[0037] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as Long Term Evolution (LTE), LTE-A, Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), New Radio (NR), etc. Furthermore, communication between terminal devices and network devices in a communication network can be performed according to any suitable generation of communication protocol, including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, future fifth-generation (5G) communication protocols, and / or any other protocols currently known or to be developed in the future. Embodiments of this disclosure can be applied to a variety of communication systems. Given the rapid development of communications, there will certainly be future types of communication technologies and systems that can be used to implement this disclosure. This should not be construed as limiting the scope of this disclosure to the systems described above.

[0038] As used herein, the term "network device" refers to a node in a communications network through which terminal devices access the network and receive services. Depending on the terminology and technology applied, a network device can refer to a base station (BS) or access point (AP), such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR-NB (also known as a gNB), a Remote Radio Unit (RRU), a Radio Header Terminal (RH), a Remote Radio Header Terminal (RRH), a relay node, or a low-power node such as a femto or pico. An example of a relay node is an Integrated Access and Backhaul (IAB) node. The Distribution Unit (DU) portion of an IAB node can perform the functionality of a "network device" and therefore can operate as a network device. In the following description, the terms "network device," "BS," and "node" are used interchangeably.

[0039] The term "terminal device" refers to any terminal device capable of wireless communication. By way of example and not limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Terminal devices may include, but are not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, smart devices, wireless customer premises equipment (CPE), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, relay nodes, and devices operating on commercial and / or industrial wireless networks. The mobile terminal (MT) portion of an IAB node can perform the functionality of a "terminal device" and therefore can operate as a terminal device. In the following description, the terms "terminal device," "communication device," "terminal," "user equipment," and "UE" are used interchangeably.

[0040] As used herein, the term "IPsec flow" refers to a data flow protected by IPsec. Packets in an IPsec flow are also called "IPsec packets." Similarly, the term "non-IPsec flow" refers to a data flow that is not protected by IPsec. Packets in a non-IPsec flow are also called "non-IPsec packets."

[0041] Example environment and working principle

[0042] Figure 1 An example environment 100 is shown in which some example embodiments of this disclosure can be implemented. For example... Figure 1 As shown, environment 100 includes terminal device 150, radio access network (RAN) 130, and core network (CN) 140. It should also be understood that example environment 100 is shown for illustrative purposes only and does not imply any limitation on the scope of this disclosure. Embodiments of this disclosure can also be applied to environments with different architectures.

[0043] Each of RAN 130 and CN 140 may include network devices or components. For example... Figure 1As shown, RAN 130 includes a Base Transceiver Station (BTS) 110, and CN 140 includes a Serving Gateway (S-GW) 120. Some network devices or components may need to process IPsec flows. For example, BTS 110 needs to process IPsec flows in both the uplink (UL) and downlink (DL) directions.

[0044] In the UL direction, BTS 110 receives ordinary packets (e.g., from end device 150), converts them into encrypted packets, and sends the encrypted packets to S-GW 120 via an IPsec tunnel. In the DL direction, BTS 110 receives encrypted IPsec packets from S-GW 120. The encrypted IPsec packets are decrypted and converted back into ordinary packets for further processing.

[0045] Figure 2A A flowchart illustrating an example process 200 for processing IPsec streams in an encrypted context is shown. IPsec packets of the IPsec stream are received via, for example, a network interface card (NIC) or receiver (RX). Then, at 210, Layer 2 (L2) processing is performed on the IPsec packets. At 220, Layer 3 (L3) processing is performed on the IPsec packets. At 230, IPsec processing is performed on the IPsec packets. Figure 2A As shown, the IPsec processing at 230 may include IPsec policy matching and Security Association (SA) lookup at 231, sequence number generation / assignment at 232, encryption / decryption operations at 233, and post-encryption / decryption operations at 234. At 240, other module / upper-layer processing is performed on the IPsec packet. The processed IPsec packet is then ready for transmission, for example, via a transmitter (TX).

[0046] Figure 2B A flowchart of an example procedure 201 for processing an IPsec stream in a decrypted state is shown. IPsec packets of the IPsec stream are received via, for example, a NIC or RX. Then, at 250, L2 processing is performed on the IPsec packets. At 260, L3 processing is performed on the IPsec packets. At 270, IPsec processing is performed on the IPsec packets. Figure 2B As shown, the IPsec processing at 270 may include IPsec security association lookup at 271, anti-replay window (ARW) check at 272, encryption / decryption operation at 273, and post-encryption / decryption operation and ARW update at 274. At 280, other module / upper-layer processing is performed on the IPsec packet. The processed IPsec packet is then ready for transmission, for example, via TX.

[0047] Implementing processes 200 and 201 on a single central processing unit (CPU) core cannot handle the high throughput requirements of 5G systems. Therefore, multiple CPU cores are used to perform parallel processing of IPsec packets. When processes 200 and 201 are implemented on multiple CPU cores, there are three main sub-processes that require synchronization between the cores. In the case of encryption, at 232, synchronization between cores is required to generate / assign sequence numbers. In the case of decryption, the ARW check at 272 and the ARW update at 274 require synchronization between cores. In the following text, the ARW check and ARW update will be collectively referred to as "ARW processing".

[0048] Therefore, when multiple CPU cores process IPsec packets in parallel, it presents challenges in performing synchronization and protecting the integrity of shared resources / data structures. There are two main conventional solutions for implementations on multiple CPU cores.

[0049] The staging method is a well-known and conventional solution. Figure 3 A block diagram 300 illustrates a hierarchical method for processing packets in IPsec flows. In this hierarchical method, after receiving packets via input interface 350, the entire packet processing is divided into multiple parts called levels, such as... Figure 3 Stages 310, 320, 330, and 340 are shown. In this method, stages 310, 320, 330, and 340 can be executed in parallel or atomic fashion. Figure 3 As shown, stages 310 and 330 are executed in parallel by cores 301, 302, 303 and cores 305, 306, 307, respectively. Stages 320 and 340 are executed atomically by cores 304 and 308, respectively.

[0050] At the synchronization point, packets converge to stages 320 and 340, which execute atomically, where execution becomes single-threaded. This protects the integrity of shared resources / data structures. Because packet processing is divided into multiple stages, packets are exchanged between CPU cores for processing. The exchange of packets from the source CPU core to the destination CPU core causes the destination CPU core to reload the packets into its cache. Currently, with the increasing efficiency of modern CPU cores, memory access is becoming a limiting factor for performance-centric programs. Reloading packets into the cache at each stage exacerbates this memory access bottleneck. The more stages, the lower the execution efficiency, leading to a greater decrease in overall throughput. Therefore, the hierarchical approach reloads packets into memory at each stage of execution, resulting in lower CPU cache utilization and lower throughput.

[0051] Run-to-completion with locks, also known as "locked RtC," is another well-known conventional solution. In this solution, the execution of groups is always constrained to a single CPU core throughout the entire processing. Parallel execution on multiple CPU cores must use synchronization mechanisms, such as spinlocks, to protect the integrity of shared resources. While locked RtC avoids the benefits of losing CPU cache (which is missing in the tiered approach), the cost of locking is very high. A lock acquired by one thread / core will suspend further execution of other threads / cores until the lock is released. This results in a very high performance penalty. The performance penalty increases with the number of CPU cores contending for the same lock. Due to this drawback, adding an extra CPU core to help achieve higher throughput after adding a few more CPU cores does not necessarily increase the expected throughput.

[0052] Table 1 shows the test results of the locked RtC method when adding additional CPU cores. As can be seen from Table 1, the locked RtC method is a non-scalable solution.

[0053] Table 1 shows the throughput achieved using the RtC method with locking.

[0054]

[0055] As mentioned above, 5G communication systems require high throughput. For example, user plane traffic rates between BTS and S-GW are on the order of gigabits (>15Gbps) and are expected to grow to 50Gbps or more. Therefore, an efficient and scalable solution is needed to handle IPsec traffic. In this context, conventional solutions, such as hierarchical approaches or RtC with locking across multiple CPU cores, each have significant drawbacks. Hierarchical approaches result in lower throughput due to packet switching between CPU cores and the loss of CPU core cache advantages. RtC with locking does not increase throughput linearly with the addition of each CPU core due to increased lock contention. We desire a solution that avoids these drawbacks.

[0056] In addition to the two conventional solutions, other solutions have been proposed, including hardware-based and software-based solutions. Hardware-based solutions utilize dedicated hardware, such as that implemented in a System-on-Chip (SoC). While processing IPsec streams in dedicated hardware can improve performance, scalability is limited by the systemic opportunities of pipelining and fast / zero-copy memory operations within the hardware. Furthermore, another drawback is that dedicated hardware cannot be helpful in deployments on commercial hardware or GPUs in the cloud. Software-based solutions fail to achieve both high throughput and linear scalability.

[0057] Given the above, a standards-compliant solution is needed to address at least one of the aforementioned and other potential problems. Such a solution could leverage parallel multi-CPU core processing, avoid grouping jumps from one core to another, and avoid the use of locks (for sequence number generation and ARW processing), thereby efficiently delivering higher throughput with linear scalability.

[0058] Embodiments of this disclosure provide a solution for processing IPsec flows. In this solution, an Security Association (SA) is determined for an incoming flow comprising multiple packets at a preprocessing module. At the preprocessing module, preprocessing is performed on the multiple packets based on security associations. Different preprocessing is performed for different types of packets. In the case of outbound packets, sequence number generation and allocation are performed on the outbound packets at the preprocessing module based on the SA. This sequence number generation and allocation would normally be performed by the processing core after L2 and L3 processing, but is performed later during IPsec processing. In the case of inbound packets, ARW checks and ARW updates are performed on the inbound packets at the preprocessing module. These ARW checks would normally be performed by the processing core during decryption, and the ARW updates would normally be performed by the processing core after performing Integrity Verification (ICV).

[0059] After preprocessing at least one of the multiple packets, the preprocessed packets are distributed to the corresponding processing cores of the parallel processing module. At the parallel processing module, parallel processing is performed on the preprocessed packets. Since the Specific Analysis (SA) of the incoming stream is determined at the preprocessing module, and preprocessing of the incoming stream packets is performed based on the SA, the need for locking, atomic operations, and hierarchical operations required by conventional solutions is eliminated at the parallel processing module. Therefore, parallel processing of the incoming stream packets is lock-free.

[0060] Several advantages can be achieved according to the exemplary embodiments of this disclosure. In one aspect, packets of the incoming stream are preprocessed based on SA prior to parallel processing. Therefore, parallel processing is lock-free and avoids the need for synchronization and atomic operations. Scalability is achieved in this way. In another aspect, hierarchical and skipping operations are avoided through SA-based preprocessing, and packets can reside on a single core throughout the entire execution of IPsec processing. This optimizes cache utilization and achieves higher throughput. Furthermore, the exemplary embodiments of this disclosure can be implemented entirely in software and therefore can also be used in cloud deployments.

[0061] In another aspect, the exemplary embodiments of this disclosure achieve high throughput and scalability without relying on any deviation from the IPsec standard. Therefore, fully standards-compliant solutions are possible and interoperable with third-party products. Furthermore, the exemplary embodiments of this disclosure do not restrict specific packets to any particular CPU core. All packets can be distributed to any / many cores. In this way, high-traffic Integrated Access and Backhaul (IAB) use cases within an SA can also be handled.

[0062] Example apparatus and method

[0063] Reference Figure 4-8 Further details are described according to exemplary embodiments of the present disclosure. These and other aspects of the present disclosure will become apparent from the following description.

[0064] Figure 4 A simplified block diagram of an example apparatus 400 for processing IPsec streams according to some example embodiments of the present disclosure is shown. Generally, apparatus 400 includes a preprocessing module 410, a primer module 420, a parallel preprocessing module 430, a distribution module 440, and a reordering module 450.

[0065] The incoming stream comprises multiple packets. Preprocessing module 410 receives the packets of the incoming stream from an input source (e.g., a NIC, Physical Function (PF), Virtual Function (VF), or host). Preprocessing module 410 is configured to determine the SA for the incoming stream and preprocess the packets of the incoming stream based on the SA.

[0066] To this end, the preprocessing module 410 can perform the following functions: determine the SA, assign sequence numbers to outbound packets based on the determined SA, and perform ARW processing on inbound packets based on the determined SA. As will be seen from the method described below, the main intent of the preprocessing module 410 is to quickly map the incoming stream to the pre-learned SA for sequence number assignment or ARW processing, and to guide the packets of the incoming stream to the next module in the device 400.

[0067] The preprocessing module 410 can be implemented on multiple cores and is not limited to a single core. Alternatively, the preprocessing module 410 can also be implemented as part of the hardware, such as a SoC.

[0068] In some example embodiments, to determine the SA for an incoming stream, the preprocessing module 410 may interact with the introductory module 420. The introductory module 420 assists the preprocessing module 410 in determining the SA of a new incoming stream. As used herein, a new incoming stream is referred to as a stream that has not been preprocessed by the preprocessing module 410 previously.

[0069] Once the packets of the incoming stream have been preprocessed at the preprocessing module 410, the preprocessed packets are sent to the distribution module 440. The distribution module 440 (e.g., a scheduler) is configured to distribute the preprocessed packets to the processing cores of the parallel processing module 430.

[0070] The parallel processing module 430 includes multiple processing cores, referred to simply as "cores". Figure 4 Cores 431, 432, and 433 are shown as examples. Since operations requiring synchronization are performed at the preprocessing module 410, processing at different cores of the parallel processing module 430 is independent, thus the cores of the parallel processing module 430 can be lock-free. Regular L2 processing, L3 processing, and the remainder of IPsec processing, excluding sequence number generation or ARW processing, are performed in each of these cores. Therefore, the remaining SA lookup and IPsec encryption / decryption (crypto) processing (including encryption / decryption and post-encryption / decryption operations) remain unchanged as part of the IPsec processing. Because there are no locks or atomic operations, adding more cores results in a linear increase in throughput.

[0071] After the core completes parallel processing, the packets can be sent to the reordering module 450. The reordering module 450 is configured to reorder the packets using any suitable packet sorting method. Therefore, the reordered packets are ready for transmission.

[0072] It should be understood that Figure 4 The modules shown are for illustrative purposes only and do not constitute any limitation on the scope of protection. Some of the modules, such as distribution module 440 and reordering module 450, may be omitted or integrated with another module. In addition, device 400 may include modules or functions not shown.

[0073] The device 400 can be used in network elements, such as base stations (e.g., eNodeB, gNodeB) and cloud RANs (e.g., CU and DU). As an example, the device can be implemented at a BTS 110 or S-GW120, such as... Figure 1As shown. Device 400 can also be used to provide any general network function that provides security gateway functionality, such as a router or user plane function that provides IPsec gateway functionality.

[0074] Now for reference Figure 5 . Figure 5 A flowchart of an example method 500 for processing IPsec flows according to some example embodiments of the present disclosure is shown. Method 500 can be implemented on any suitable device, such as... Figure 4 The apparatus 400 is shown. For illustrative purposes, it should be understood that method 500 may include additional boxes not shown and / or some blocks shown may be omitted, and the scope of this disclosure is not limited thereto.

[0075] In block 510, an SA is determined for an incoming stream comprising multiple packets. For example, after receiving one or more packets of an incoming stream, the preprocessing module 410 may determine the SA for the incoming stream. In some example embodiments, the preprocessing module 410 may determine the SA through a normal SA lookup process.

[0076] In some example embodiments, the preprocessing module 410 may maintain or utilize a table that stores mapping information between IPsec flows and predetermined SAs. This table may be referred to as a "first table" or a "whitelist table." In such example embodiments, upon receiving a packet of an incoming flow, the preprocessing module 410 may look up the whitelist table to find the predetermined SA of the incoming flow. The whitelist table is dynamically populated and the mapping information may be stored in any suitable manner.

[0077] For example, a whitelist can be implemented as a hash table. A whitelist can store information indicating a mapping between the receive-side scaled (RSS) hash of an IPsec flow and its associated SA references. As used herein, the term "SA reference" refers to an index or identifier for a specific SA. In this case, the RSS hash of each received packet is used as the key of the whitelist to quickly find the associated SA reference. If the RSS hash corresponds to an entry that includes multiple SA references, an additional lookup based on the value of the Security Parameter Index (SPI) can be performed.

[0078] The following will refer to Figure 6 A detailed description of such example embodiments is provided.

[0079] After determining the SA, method 500 proceeds to block 520. In block 520, preprocessing is performed on multiple packets based on the SA for the incoming stream. Different preprocessing can be performed on different types of packets.

[0080] For a specific packet among multiple packets, the preprocessing module 410 can determine whether the specific packet is an outbound packet or an inbound packet. If the specific packet is an outbound packet, a sequence number is generated based on the sequence number counter of the determined SA and assigned to the specific packet. For example, if the SA reference found in the whitelist table is an outbound SA reference, the SA is used to assign the sequence number to the specific packet. Based on the packet processing architecture, the sequence number used by the specific packet can be included as part of the packet metadata.

[0081] The primary purpose of pre-assigning sequence numbers to packets is to ensure that packets can be distributed to parallel processing cores. Therefore, locks or intermediate atomic levels are no longer needed to synchronize sequence number allocation between cores.

[0082] In some example embodiments, a sequence number can be generated by incrementing, for example, the value of a sequence number counter in the SA. In some example embodiments, it may be necessary to fragment a particular packet at a later stage. Accordingly, the preprocessing module 410 can determine the number of fragments into which a particular packet will be divided. The number of fragments can be determined based on the size of the particular packet, the packet size available for transmission, and security associations (e.g., information about encryption overhead). A sequence number can then be generated by incrementing the value of the sequence number counter by the number of fragments.

[0083] In such example embodiments, when fragmentation of a specific packet is performed at a later stage of device 400, the sequence number of the newly created fragment will be a consecutive increment of the original packet sequence number. This also ensures that the correct sequence number is assigned to the segmented traffic.

[0084] If a specific packet is an inbound packet, an ARW check is performed based on the SA. The preprocessing module 410 verifies whether the sequence number of the specific packet is within the ARW of the SA and includes the verification result in the specific packet. The ARW status can be populated in the packet's metadata. For example, if the SA reference found in the whitelist table is an inbound SA reference, the SA is used to verify whether the packet's sequence number is within the ARW of the SA. The specific packet is tagged accordingly based on the success or failure of the ARW check.

[0085] Furthermore, in some example embodiments, the ARW of the SA can be updated based on feedback from parallel processing at the parallel processing module 430. For example, feedback messages from the respective cores 431, 432, and 433 of the parallel processing module 430 can be queued into the preprocessing module 410. The ARW of the SA can be updated accordingly based on the feedback messages. In this way, the cores of the parallel processing module 430 do not need to take locks or synchronize processing atomically.

[0086] In block 530, after preprocessing is performed on at least one of the multiple packets, parallel processing is performed on at least one of the multiple packets. In other words, once the packets of the incoming stream have been preprocessed, the preprocessed packets are sent to distribution module 440. For example, after performing sequence number assignment on outgoing packets, outgoing packets can be sent to distribution module 440. Similarly, after performing ARW checks on inbound packets, inbound packets can be sent to distribution module 440. Distribution module 440 distributes the preprocessed packets to the processing core of parallel processing module 430.

[0087] Because the sequence number of the outbound packet or the ARW state is pre-filled in the metadata of the inbound packet, the sequence number generation or ARW processing, which would otherwise require using locks or creating additional levels for synchronization between cores, is eliminated at the parallel processing module 430. For outbound packets, or in other words, in the case of an encryption process, cores 431, 432, and 433 can simply copy the sequence number present in the packet's metadata to the encryption header and continue the remaining processing. Alternatively, for inbound packets, or in other words, in the case of a decryption process, cores 431, 432, and 433 can discard or continue processing the packet based on the ARW state.

[0088] As described in reference box 510 above, in some example embodiments, the preprocessing module 410 may determine the SA by using a whitelist table. Now refer to Figure 6 . Figure 6 A flowchart of an example method 600 for determining an SA according to some example embodiments of the present disclosure is shown. Method 600 can be considered as Figure 5 The specific implementation of frame 510.

[0089] In block 610, upon receiving a packet of an incoming stream, preprocessing module 410 determines, based on the received packet, whether the incoming stream maps to at least one predetermined security association indicated in a whitelist table. For example, the RSS hash value of the received packet can be calculated and used as the key of the whitelist table.

[0090] If it is determined in box 610 that the incoming stream maps to at least one predetermined SA indicated in the whitelist table, then method 600 proceeds to box 620. In box 620, preprocessing module 410 determines the SA for the incoming stream from at least one predetermined SA. For example, if the RSS hash of a packet corresponds to an SA reference in the whitelist table, the SA indicated by the SA reference can be determined as the SA for the incoming stream.

[0091] If a whitelist stores mapping information between a specific incoming stream and its associated Streaming Entities (SAs), then the specific incoming stream is a learned stream. In such example embodiments, the whitelist can be used to accelerate the grouping of learned streams.

[0092] If it is determined in box 610 that the incoming flow is not mapped to any predefined SA indicated in the whitelist table, the packet is sent from preprocessing module 410 to intro module 420. Intro module 420 can determine whether the incoming flow is an IPsec flow or a non-IPsec flow. In other words, intro module 420 can determine whether the packet is an IPsec packet or a non-IPsec packet.

[0093] In some example embodiments, the intro module 420 may maintain a table to indicate non-IPsec flows. Such a table is referred to as a "second table" or "blacklist table." Entries in the blacklist table indicate non-IPsec flows. Similar to a whitelist table, the blacklist table may be implemented as a hash table.

[0094] like Figure 6 As shown, in such an example embodiment, method 600 may proceed to block 630. At block 630, initiation module 420 determines whether the incoming flow matches an entry in the blacklist table based on the packet received from preprocessing module 410. If, at block 630, it is determined that the incoming flow matches an entry in the blacklist table, method 600 proceeds to block 680. For example, if the hash value of the packet received from preprocessing module 410 matches an entry in the blacklist table, it means the incoming flow is a non-IPsec flow, and therefore the packet is identified as a non-IPsec packet. In this case, method 600 proceeds to block 680. At block 680, the non-IPsec packet is sent out for normal packet processing.

[0095] If, at box 630, it is determined that the incoming flow does not match an entry in the blacklist table, then method 600 proceeds to box 640. For example, if the hash value of a packet received from preprocessing module 410 does not match an entry in the blacklist table, it means that further determination is needed to determine whether the incoming flow is a non-IPsec flow. In this case, method 600 proceeds to box 640.

[0096] In box 640, intro module 420 performs L2 and L3 processing on packets to determine whether a packet is mapped to an inbound or outbound flow. L2 and L3 processing includes an IPsec policy lookup to determine whether a packet is mapped to an inbound (i.e., decrypted) flow or an outbound (i.e., encrypted) flow. In box 650, intro module 420 determines whether an incoming flow is an IPsec flow or a non-IPsec flow. For example, if a packet is mapped to either an inbound or outbound flow, the inbound flow is determined to be an IPsec flow. If a packet is neither mapped to an inbound nor an outbound flow, the incoming flow is determined to be a non-IPsec flow.

[0097] If, at box 650, the incoming flow is determined to be a non-IPsec flow, this means that packets from the incoming flow do not require IPsec processing. In this case, method 600 proceeds to boxes 670 and 680. At box 670, the blacklist table is updated to indicate the incoming flow. Therefore, at box 630, subsequent packets of the incoming flow will be identified as non-IPsec packets and will be sent directly for normal processing.

[0098] In such example embodiments, the blacklist table is dynamically updated to indicate non-IPsec flows. This allows for the rapid identification of non-IPsec packets that do not require IPsec processing and further accelerates processing at intro module 420. Alternatively, in some example embodiments, the blacklist table may be maintained by preprocessing module 410.

[0099] Continuing with method 600, if in box 650 the incoming flow is determined to be an IPsec flow, this means that the packets of the incoming flow require IPsec processing. In this case, method 600 proceeds to box 660. In box 660, intro module 420 determines the SA of the incoming packet based on the pre-defined SA established for the IPsec flow. For example, intro module 420 may look up or retrieve an SA reference for an SA created during the negotiation to establish a secure connection. In other words, if identified as an IPsec flow, depending on whether the packet is an encrypted or decrypted flow, the appropriate SA lookup is performed, and the associated outbound or inbound SA reference for the incoming flow is identified.

[0100] In this case, the packet's metadata can be updated to include the identified SA reference or information about the SA reference. Additional flags can also be included in the packet's metadata. These additional flags can indicate that the packet has been sent to the intro module 420 and include SA information from the incoming stream.

[0101] Upon completion of box 660, the packet, as an IPsec packet, is sent back to preprocessing module 410. Preprocessing module 410 can then update the whitelist table to store mapping information between incoming flows and the determined SAs. For example, based on additional flags in the packet's metadata and associated SA references, the whitelist table is updated to store information mapping the RSS hash of the incoming flow to associated SA references. Therefore, by using a dynamically populated whitelist table, the SA for subsequent packets of the same incoming flow can be quickly determined. In this way, there is no need to run intro module 420 again.

[0102] In some example embodiments, if multiple packets from the same incoming stream are received, a specific packet (e.g., the first packet) of the incoming stream can be sent to introductory module 420. The remaining packets can be buffered in preprocessing module 410. Once the specific packet (e.g., the first packet) is re-enqueued after processing by introductory module 420, the remaining buffered packets can be dequeued and mapped to SA references. In this way, the performance of preprocessing module 410 can be further optimized.

[0103] As can be seen from the above, each new IPsec flow triggers the intro module 420 only once. The intro module 420 is used to ensure that the whitelist table is updated with the associated SA reference.

[0104] It should be understood that Figure 6 The boxes shown are for illustrative purposes only. Methods for determining an SA may include more or fewer boxes. In some example embodiments, a blacklist table may not be maintained, and box 630 may be omitted. In such example embodiments, if at box 610 it is determined that an incoming flow does not map to any predetermined SA indicated in the whitelist table, method 600 may proceed to box 640. In some example embodiments, non-IPsec flows may be filtered and not allowed to enter preprocessing module 410. For example, apparatus 400 may be dedicated to processing IPsec flows. In such example embodiments, boxes 630, 640, 650, 670, and 680 may be omitted.

[0105] According to the above reference Figure 5 and Figure 6 The description states that the processing flow may differ for different groups. Figure 7A A block diagram is shown of a processing flow 701 for packets of new IPsec flows that have not been preprocessed by the preprocessing module 410. Processing flow 701 occurs as part of the introductory module 420 when a new IPsec flow enters the device 400 and needs to be learned via SA reference discovery. Figure 7B A block diagram of a processing flow 702 for packets of an IPsec flow that has already been preprocessed by preprocessing module 410 is shown. Processing flow 702 occurs when the SA information of the IPsec flow has been populated in a whitelist table. From Figure 7A and 7B It can be seen that by using a whitelist, the main scenario processing flow 702 has fewer steps than the processing flow 701, resulting in faster grouping processing.

[0106] Figure 7C A block diagram of a processing flow 703 for a new non-IPsec flow packet is shown. Processing flow 703 occurs when a new non-IPsec flow enters device 400 and needs to be learned by introductory module 420. Figure 7DA block diagram of processing flow 704 for packets of preprocessed non-IPsec flows is shown. Processing flow 704 occurs when information about the non-IPsec flow has already been populated in a blacklist. From Figure 7C and 7D It can be seen that by using a blacklist, packets of non-IPsec flows can be quickly identified, and the processing load can be further reduced.

[0107] Several tests have been conducted to compare the locked RtC method with the proposed solution. Table 2 shows the test results for the sequence number generation (encryption) scenario. Table 3 shows the test results for the ARW processing (decryption) scenario. Both Table 2 and Table 3 show the maximum number of packets achieved without packet loss relative to the total number of cores used in the processing core pool.

[0108] Table 2 Test results under serial number generation conditions

[0109]

[0110] Figure 8 A graph 800 corresponding to Table 2 shows the throughput in the case of sequence number generation. In graph 800, curve 810 shows the throughput using the RtC method with locking, while curve 820 shows the throughput of the proposed solution.

[0111] Table 3 Test results under ARW processing conditions

[0112]

[0113] From Table 2, Table 3 and Figure 8 The results show that the scalability of the RtC method with locking decreases significantly with the increase in the number of cores used. This is because contention for locks with more cores increases exponentially, leading to a reduction in the overall benefit of adding cores. In contrast, the proposed solution shows that packet processing throughput increases linearly with the increase in cores. Furthermore, the table shows the percentage improvement achieved using the proposed solution. The proposed solution outperforms and achieves both the expected goals of high performance and scalability.

[0114] As can be seen from the foregoing, according to the exemplary embodiments of this disclosure, a linear increase in throughput proportional to the number of additional cores can be implemented. For a fixed number of cores, as shown in Tables 2 and 3... Figure 8As shown, the example embodiments of this disclosure can significantly increase overall throughput. By eliminating the synchronization requirements between parallel processing cores, the example embodiments of this disclosure create truly independent parallel processing cores, thereby improving throughput compared to conventional solutions. Furthermore, since the example embodiments of this disclosure conform to existing RFC standards and do not introduce any new parameters to external interfaces, they can be implemented without any additional modifications on either end.

[0115] Example embodiments and devices

[0116] In some example embodiments, the apparatus capable of performing method 500 may include components for performing the various steps of method 500. The method may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.

[0117] In some example embodiments, the apparatus capable of performing method 500 includes: means for determining a security association for an incoming stream, the incoming stream including a plurality of packets; means for performing preprocessing on the plurality of packets based on the security association; and means for performing parallel processing on at least one of the plurality of packets in response to performing preprocessing on at least one of the plurality of packets.

[0118] In some example embodiments, the components for determining a security association for an incoming flow include: components for determining, in response to receiving a first packet of the incoming flow, whether the incoming flow is mapped to at least one predetermined security association indicated in a first table, the first table storing mapping information between Internet Protocol Security (IPsec) flows and predetermined security associations; and components for determining a security association from at least one predetermined security association based on the determination that the incoming flow is mapped to at least one predetermined security association.

[0119] In some example embodiments, the apparatus capable of performing method 500 further includes: a component for determining whether an incoming flow is an IPsec flow based on a determination that the incoming flow is not mapped to any predetermined security association indicated in the first table; and a component for determining a security association based on a predetermined security association established for the IPsec flow based on the determination that the incoming flow is an IPsec flow.

[0120] In some example embodiments, the apparatus capable of performing method 500 further includes: a component for updating a first table to store mapping information between incoming streams and security associations.

[0121] In some example embodiments, an apparatus for determining whether an incoming flow is an IPsec flow includes: components for determining whether the incoming flow matches an entry in a second table based on a first packet, the entries in the second table indicating non-IPsec flows; components for performing layer 2 and layer 3 processing on the first packet to determine whether the first packet is mapped to an inbound or outbound flow based on the determination that the incoming flow does not match an entry in the second table; and components for determining that the incoming flow is an IPsec flow based on the determination that the first packet is mapped to an inbound or outbound flow.

[0122] In some example embodiments, the apparatus capable of performing method 500 further includes: in response to receiving a second packet of another incoming flow, determining whether the other incoming flow matches an entry in a second table based on the second packet; performing layer 2 and layer 3 processing on the second packet to determine whether the second packet is mapped to an inbound flow or an outbound flow based on the determination that the other incoming flow does not match an entry in the second table; and updating the second table to indicate the other incoming flow based on the determination that the second packet is neither mapped to an inbound flow nor an outbound flow.

[0123] In some example embodiments, the components for performing preprocessing on multiple packets based on security association include: components for determining whether a third packet among the multiple packets is an outbound packet; and components for assigning a sequence number to the third packet based on a security association sequence number counter according to the determination that the third packet is an outbound packet.

[0124] In some example embodiments, the component that assigns a sequence number to a third packet based on a security association includes: a component that determines the number of segments into which the third packet will be divided based on the size of the third packet, the packet size available for transmission, and the security association; and a component that determines the sequence number by incrementing the value of the sequence number counter by the number of segments.

[0125] In some example embodiments, the components for performing preprocessing on multiple packets based on security association include: components for determining whether a fourth packet among the multiple packets is an inbound packet; components for verifying whether the sequence number of the fourth packet falls within the anti-replay window of the security association based on the determination that the fourth packet is an inbound packet; and components for including the verification result in the fourth packet.

[0126] In some example embodiments, the apparatus capable of performing method 500 further includes: a component for updating the anti-replay window of the security association based on feedback from parallel processing.

[0127] Figure 9This is a simplified block diagram of a device 900 suitable for implementing embodiments of the present disclosure. The device 900 may be provided to implement the apparatus 400. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processors 910, and one or more communication modules 940 coupled to the processors 910.

[0128] Communication module 940 is used for bidirectional communication. Communication module 940 has at least one antenna to facilitate communication. The communication interface can represent any interface necessary for communication with other network elements.

[0129] Processor 910 may be any type suitable for a local technology network and may include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture, as non-limiting examples. Device 900 may have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock of a synchronous main processor.

[0130] Memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 924, electrically programmable read-only memory (EPROM), flash memory, hard disk, optical disc (CD), digital video disc (DVD), and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 922 and other volatile memories that do not persist during power-off periods.

[0131] Computer program 930 includes computer-executable instructions that are executed by the associated processor 910. Program 930 may be stored in ROM 920. Processor 910 may perform any suitable actions and processes by loading program 930 into RAM 920.

[0132] Embodiments of this disclosure may be implemented via program 930 so that device 900 can execute the reference. Figures 5 to 6 Any process described in this disclosure. Embodiments of this disclosure may also be implemented in hardware or a combination of software and hardware.

[0133] In some embodiments, program 930 may be tangibly contained in a computer-readable medium, which may be contained in device 900 (such as memory 920) or other storage device accessible to device 900. Device 900 may load program 930 from the computer-readable medium into RAM 922 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Figure 10An example of a computer-readable medium 1000 in the form of a CD or DVD is shown. A program 930 is stored on the computer-readable medium.

[0134] It should be understood that future networks may leverage Network Function Virtualization (NFV), a network architecture concept that proposes virtualizing network node functions as “building blocks” or entities that can be operationally connected or linked together to provide services. Virtualized network functions (VNFs) may include one or more virtual machines running computer program code using standard or general-purpose servers instead of custom hardware. Cloud computing or data storage may also be used. In radio communications, this may mean performing node operations, at least partially, in a central / centralized unit (CU, such as a server, host, or node), which is operationally coupled to a distributed unit (DU, such as a radio head / node). Node operations may also be distributed among multiple servers, nodes, or hosts. It should also be understood that the distribution of labor between core network operations and base station operations may vary depending on the implementation method.

[0135] In one embodiment, the server may generate a virtual network through which it communicates with the distribution unit. Generally, virtual networking may involve the process of combining hardware and software network resources and network functionality into a single software-based management entity (virtual network). Such virtual networks can provide flexible operational distribution between the server and the wireless headend / node. In practice, any digital signal processing task can be performed in the CU or DU, and the boundary of responsibility transfer between the CU and DU can be selected depending on the implementation.

[0136] Therefore, in one embodiment, a CU-DU architecture is implemented. In such a case, device 900 may be included in a central unit (e.g., a control unit, an edge cloud server, a server) operatively coupled (e.g., via a wireless or wired network) to distribution units (e.g., remote radio headends / nodes). That is, the central unit (e.g., the edge cloud server) and the distribution units may be independent devices communicating with each other via a radio path or via a wired connection. Alternatively, they may reside in the same entity communicating via a wired connection or the like. The edge cloud or edge cloud server may serve multiple distribution units or wireless access networks. In one embodiment, at least some of the described processes may be performed by the central unit. In another embodiment, device 900 may alternatively be included in a distribution unit, and at least some of the described processes may be performed by the distribution unit.

[0137] In one embodiment, the execution of at least some of the functionality of device 900 can be shared between two physically separate devices (DU and CU) forming an operational entity. Thus, the apparatus can be seen to depict an operational entity comprising one or more physically separate devices for performing at least some of the described processes. In one embodiment, such a CU-DU architecture can provide flexible operation distribution between the CU and DU. In practice, any digital signal processing task can be performed in either the CU or the DU, and the boundary of responsibility transfer between the CU and DU can be selected depending on the implementation. In one embodiment, device 900 controls the execution of processing regardless of the location of the devices or where the process / function is performed.

[0138] In general, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software executable by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, as non-limiting examples, the blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0139] This disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions that execute in a device targeting a real or virtual processor, such as those included in a program module, to perform the functions described above. Figure 5-6 Method 500 or 600 is described. Generally, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided as needed. The machine-executable instructions of a program module can be executed on a local or distributed device. In a distributed device, the program module can reside on local and remote storage media.

[0140] Program code for implementing the methods of this disclosure can be written using any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code can be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine, partially on a remote machine, or entirely on a remote machine or server.

[0141] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0142] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples of computer-readable storage media include electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0143] Furthermore, while the operations are described in a specific order, this should not be construed as requiring such operations to be performed in the specific order or sequence shown, or requiring all illustrated operations to be performed to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several details of specific implementations are included in the foregoing discussion, these details should not be construed as limiting the scope of this disclosure, but rather as descriptions of features specific to particular embodiments. Certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0144] Although this disclosure is described in language specific to structural features and / or methodological actions, it should be understood that this disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as examples of implementing the claims.

Claims

1. A device for communication, comprising: At least one processor; as well as At least one memory, including computer program code; The at least one memory and the computer program code are configured, together with the at least one processor, to cause the device to: Determine security associations for an incoming stream, which includes multiple packets; Preprocessing is performed on the plurality of groups based on the security association, wherein the preprocessing includes at least one of the following: sequence number generation and allocation, or anti-replay window processing; as well as In response to performing the preprocessing on at least one of the plurality of packets, parallel processing is performed on the at least one of the plurality of packets. The device is further configured to: Determine whether the fourth group among the plurality of groups is an inbound group; If it is determined that the fourth group is the inbound group, verify whether the sequence number of the fourth group falls within the anti-replay window associated with the security; as well as The results of the verification are included in the fourth group.

2. The apparatus of claim 1, wherein the apparatus is further configured to: In response to receiving a first packet of the incoming stream, based on the first packet, it is determined whether the incoming stream is mapped to at least one predetermined security association indicated in a first table, the first table storing mapping information between Internet Protocol Security (IPsec) streams and predetermined security associations; and If it is determined that the incoming stream is mapped to the at least one predetermined security association, the security association is determined from the at least one predetermined security association.

3. The apparatus of claim 2, wherein the apparatus is further configured to: If it is determined that the incoming flow is not mapped to any predetermined security association indicated in the first table, determine whether the incoming flow is an IPsec flow; and If it is determined that the incoming flow is the IPsec flow, the security association is determined based on the predetermined security association established for the IPsec flow.

4. The apparatus of claim 3, wherein the apparatus is further configured to: The first table is updated to store mapping information between the incoming stream and the security association.

5. The apparatus of claim 3, wherein the apparatus is further configured to: Based on the first group, it is determined whether the incoming flow matches an entry in a second table, where the entries in the second table indicate non-IPsec flows; If it is determined that the incoming flow does not match an entry in the second table, layer 2 and layer 3 processing are performed on the first group to determine whether the first group is mapped to an inbound or outbound flow; and If it is determined that the first packet is mapped to an inbound or outbound flow, then the incoming flow is determined to be the IPsec flow.

6. The apparatus of claim 5, wherein the apparatus is further configured to: In response to receiving a second packet of another incoming stream, determine whether the other incoming stream matches an entry in the second table based on the second packet; If it is determined that the additional incoming flow does not match the entry in the second table, layer 2 and layer 3 processing are performed on the second group to determine whether the second group is mapped to an inbound flow or an outbound flow; as well as If it is determined that the second group is not mapped to either an inbound or outbound flow, the second table is updated to indicate the additional inbound flow.

7. The apparatus of claim 1, wherein the apparatus is further configured to: Determine whether the third group among the plurality of groups is an outbound group; and If the third packet is determined to be the outbound packet, a serial number is assigned to the third packet based on the security-associated serial number counter.

8. The apparatus of claim 7, wherein the apparatus is further configured to: Based on the size of the third packet, the available packet size for transmission, and the security association, determine the number of segments into which the third packet will be divided; and The serial number is determined by incrementing the value of the serial number counter by the number of segments.

9. The apparatus of claim 1, wherein the apparatus is further configured to: The anti-replay window associated with the security is updated based on the feedback from the parallel processing.

10. A method for communication, comprising: Determine security associations for an incoming stream, which includes multiple packets; Preprocessing is performed on the multiple groups based on the security association; as well as In response to performing the preprocessing on at least one of the plurality of packets, wherein the preprocessing includes at least one of the following: sequence number generation and allocation, or anti-replay window processing, parallel processing is performed on the at least one of the plurality of packets. The preprocessing of the multiple groups based on the security association includes: Determine whether the fourth group among the plurality of groups is an inbound group; If the fourth packet is determined to be the inbound packet, verify whether the sequence number of the fourth packet falls within the anti-replay window associated with the security; and The results of the verification are included in the fourth group.

11. The method of claim 10, wherein determining the security association for the incoming stream comprises: In response to receiving a first packet of the incoming stream, the system determines, based on the first packet, whether the incoming stream is mapped to at least one predetermined security association indicated in a first table, the first table storing mapping information between Internet Protocol Security (IPsec) streams and predetermined security associations; as well as If it is determined that the incoming stream is mapped to the at least one predetermined security association, the security association is determined from the at least one predetermined security association.

12. The method of claim 11, further comprising: If it is determined that the incoming flow is not mapped to any predetermined security association indicated in the first table, determine whether the incoming flow is an IPsec flow; as well as If it is determined that the incoming flow is the IPsec flow, the security association is determined based on the predetermined security association established for the IPsec flow.

13. The method of claim 12, further comprising: The first table is updated to store mapping information between the incoming stream and the security association.

14. The method of claim 12, wherein determining whether the incoming flow is an IPsec flow comprises: Based on the first group, it is determined whether the incoming flow matches an entry in the second table, where the entries in the second table indicate non-IPsec flows; If it is determined that the incoming flow does not match the entry in the second table, layer 2 and layer 3 processing are performed on the first group to determine whether the first group is mapped to an inbound flow or an outbound flow; as well as If it is determined that the first packet is mapped to an inbound or outbound flow, then the incoming flow is determined to be the IPsec flow.

15. The method of claim 14, further comprising: In response to receiving a second packet of another incoming stream, determine whether the other incoming stream matches an entry in the second table based on the second packet; If it is determined that the additional incoming flow does not match the entry in the second table, layer 2 and layer 3 processing are performed on the second group to determine whether the second group is mapped to an inbound flow or an outbound flow; as well as If it is determined that the second group is not mapped to either an inbound or outbound flow, the second table is updated to indicate the additional inbound flow.

16. The method of claim 10, wherein performing the preprocessing on the plurality of packets based on the security association comprises: Determine whether the third group among the plurality of groups is an outbound group; as well as If the third packet is determined to be the outbound packet, a serial number is assigned to the third packet based on the security-associated serial number counter.

17. The method of claim 16, wherein assigning the serial number to the third group based on the serial number counter of the security association comprises: Based on the size of the third packet, the available packet size for transmission, and the security association, the number of segments into which the third packet will be divided is determined; as well as The serial number is determined by incrementing the value of the serial number counter by the number of segments.

18. The method of claim 10, further comprising: The anti-replay window associated with the security is updated based on the feedback from the parallel processing.

19. An apparatus for communication, comprising: Components for determining security associations for an incoming flow, the incoming flow comprising multiple packets; A component for performing preprocessing on the plurality of groups based on the security association, wherein the preprocessing includes at least one of the following: serial number generation and allocation, or anti-replay window processing; as well as A component for performing parallel processing on at least one of the plurality of packets in response to performing the preprocessing on at least one of the plurality of packets. The components used to perform the preprocessing include: A component used to determine whether the fourth group among the plurality of groups is an inbound group; A component for verifying whether the sequence number of the fourth packet falls within the security-associated anti-replay window if it is determined that the fourth packet is the inbound packet; and Components used to include the results of the verification in the fourth group.

20. A computer-readable storage medium comprising program instructions stored thereon, the instructions causing the device, when executed by a means, to: Determine security associations for an incoming stream, which includes multiple packets; Preprocessing is performed on the plurality of groups based on the security association, wherein the preprocessing includes at least one of the following: sequence number generation and allocation, or anti-replay window processing; as well as In response to performing the preprocessing on at least one of the plurality of packets, parallel processing is performed on the at least one of the plurality of packets. The device is further configured to: Determine whether the fourth group among the plurality of groups is an inbound group; If it is determined that the fourth group is the inbound group, verify whether the sequence number of the fourth group falls within the anti-replay window associated with the security; as well as The results of the verification are included in the fourth group.

Images