Internet Protocol Security (IPsec) Security Association (SA) Balancing between Heterogeneous Cores in a Multi-Controller System

Abstract

Embodiments of the present disclosure relate to balancing Internet Protocol Security (IPsec) security associations (SAs) between heterogeneous cores in a multi-controller system. Systems and methods are provided for load balancing IPsec SAs between different heterogeneous cores. Balancing of IPsec SAs is performed using software implementations of IPsec offload and / or hardware implementations of IPsec offload. By balancing processing functions related to the orchestration of IPsec SAs between hardware and software, these methods achieve enhanced optimization, improved user experience, and enhanced product performance in networks using IPsec. For example, an IPsec session is initiated, and it is determined whether resource limits for a hardware-based IPsec accelerator have been reached. If the limits for the hardware-based IPsec accelerator have been reached, processing of the IPsec SA for the initiated IPsec session is offloaded to the software-based IPsec accelerator.

Description

Background Art

[0001] Optical communication technology is used in some computing networks to increase the speed, cable length, and total bandwidth of communications between different networked devices (e.g., between server devices to network routers, network switches). One networking application that uses optical communication technology (e.g., fiber optic cables, optical transceiver modules) is storage networking. In particular, a storage area network (SAN) can use fiber optic connections to achieve long-distance network communications. For example, when using optical communication technology and optical interfaces, a SAN can provide data rates of up to 128 Gbps across metropolitan distances (e.g., up to about 6 miles or 10 kilometers). In addition, optical components such as optical transceivers are increasingly being integrated into networking devices. For example, switches used in storage networking can be equipped with optical transceivers to take advantage of the enhanced capabilities of optical communication technology to address the unique needs of storage networking, such as data growth, demanding workloads, and high performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The present disclosure according to one or more various embodiments is described in detail with reference to the following drawings. The drawings are provided for illustrative purposes only and depict only typical or exemplary embodiments. These drawings are provided to facilitate the reader's understanding of the various embodiments and should not be construed as limiting the breadth, scope, or applicability of the present disclosure. It should be noted that for clarity and ease of illustration, these drawings are not necessarily drawn to scale.

[0003] Figure 1 An example networking environment is illustrated in which Internet Protocol security (IPsec) security associations (SAs) and disclosed IPsec SA balancing techniques may be implemented according to the present disclosure;

[0004] Figure 2 An example of a multi-controller networking environment for implementing the disclosed IPsec SA balancing technique according to the present disclosure is illustrated;

[0005] Figure 3 An example of a multi-cluster networking environment for implementing the disclosed IPsec SA balancing technique according to the present disclosure is illustrated;

[0006] Figure 4 An example of an IPsec networking device implementing one aspect of the disclosed IPsec SA balancing technique is depicted in accordance with the present disclosure;

[0007] Figure 5 Depicted are examples of IPsec networking devices implementing another aspect of the disclosed IPsec SA balancing techniques in accordance with the present disclosure;

[0008] Figure 6is an operational flow diagram illustrating an example method for implementing the disclosed IPsec SA balancing techniques according to implementations of the present disclosure; and

[0009] Figure 7 Depicted is a block diagram of an example computer system in which various embodiments described herein may be implemented.

[0010] The drawings are not intended to be exhaustive or to limit the various embodiments to the precise form disclosed.It should be understood that the various embodiments can be practiced with modification and alteration. DETAILED DESCRIPTION

[0011] Internet Protocol Security (IPsec) IPsec encryption is used in some network deployments as a protocol to support data encryption for security purposes. In an example of a network architecture that employs IPsec encryption, an access point (AP) can establish an encrypted IPsec tunnel using a controller. Uplink and / or downlink traffic is then sent through the established IPsec tunnel in a manner that supports secure communication, since information packets are transmitted across network boundaries. As network interface rates increase with the continued expansion of distributed computing (e.g., 100 Gbps), it is desirable to minimize the processing overhead associated with IPsec. To address these issues, there are a variety of available implementation options dedicated to primarily handling IPsec-related functions (also referred to herein as IPsec offload), which can therefore be used to improve the processing efficiency of the entire system. For example, IPsec offload can be used to reduce CPU cycles used for computationally intensive operations (e.g., encryption / decryption tasks are computationally intensive in IPsec processing tasks).

[0012] IPsec offload implementations range from software implementations using optimized CPU instructions to hardware implementations that offload various aspects of IPsec packet processing. For example, a hardware implementation of IPsec hardware offload can utilize a cryptographic accelerator integrated circuit (IC) chip (e.g., on an expansion board) to offload computationally intensive tasks such as IPsec encryption / decryption and compression / decompression, where IPsec can run on different cores. By offloading IPsec processing from the host processor using either hardware-based or software-based implementations, its efficiency can be improved. For example, a system that uses a hardware implementation (such as a cryptographic accelerator chip) for IPsec offload can achieve throughputs of 1 Gbps to 2 GBps. For example, a system that uses a software implementation (e.g., a software module that performs the encryption / decryption functions of IPsec) can achieve throughputs of 100 Mbps to 300 Mbps.

[0013] However, there are design tradeoffs that can be attributed to using software or hardware implementations of IPsec offload. For example, software implementations of IPsec offload still consume the cost of the host system's CPU core (related to not running on separate dedicated hardware). Therefore, when using software implementations for IPsec offload, the CPU may become a bottleneck, providing lower performance for data services (e.g., 100 Mbps to 300 Mbps throughput) compared to hardware implementations. In contrast, the host system's CPU core is not interfered with by hardware implementations of IPsec offload because the IPsec encryption / decryption functions are performed within the cryptographic accelerator chip, for example, without consuming the processing resources of the host core. Therefore, with hardware implementations of IPsec offload, there is a limit on the number of IPsec tunnels that a controller can support simultaneously. As a result, some computer architectures (such as extended multi-controller systems) may require a greater number of secure connections than the IPsec tunneling capabilities of the hardware implementation used for IPsec offload can support. For example, there may be many controllers requiring secure connections, which is greater than the number of IPsec tunnels that the hardware implementation used for IPsec offload can support simultaneously. To optimize IPsec offload, the disclosed embodiments include methods and systems that support various distributions of IPsec functionality, such as in a multi-controller system, in a manner that is flexibly and adaptively optimized for the specific network architecture being deployed.

[0014] The disclosed embodiments can utilize a hybrid IPsec offload approach that leverages the benefits of both hardware and software implementations of IPsec offload. In other words, the disclosed embodiments use software implementations of IPsec offload and / or hardware implementations of IPsec offload to load balance IPsec security associations (SAs) across heterogeneous cores in a multi-controller system. Consequently, the disclosed embodiments can achieve enhanced optimization, improved user experience, and enhanced product performance in networks that utilize IPsec for security features.

[0015] exist Figure 1 , an example network configuration 100 is depicted that can be used in various applications to implement IPsec SA load balancing systems and methods. For example, network configuration 100 can be implemented for an organization, such as a business, an educational institution, a government entity, a healthcare institution, or other organization. The figure shows an example of a configuration implemented with an organization having multiple users (or, at least multiple client devices 110) and possibly multiple physical or geographic sites 102, 132, 142. Network configuration 100 can include a primary site 102 in communication with a network 120. Network configuration 100 can also include one or more remote sites 132, 142 in communication with network 120.

[0016] The primary site 102 may include a primary network, which may be, for example, an office network, a home network, or another network installation. The primary site 102 network may be a private network, such as one that may include security and access controls to limit access to authorized users of the private network. Authorized users may include, for example, employees of a company at the primary site 102, residents of a home, customers of the business, and the like.

[0017] In the illustrated example, the primary site 102 includes a controller 104 that communicates with a network 120. The controller 104 can provide communication with the network 120 for the primary site 102, although it may not be the only point of communication between the primary site 102 and the network 120. A single controller 104 is shown, although the primary site may include multiple controllers and / or multiple communication points with the network 120. In some embodiments, the controller 104 communicates with the network 120 through a router (not shown). In other embodiments, the controller 104 provides router functionality to devices in the primary site 102. The network configuration 100 also includes controllers 196a and 196b distributed at remote sites 132 and 142, respectively. Although a single controller 196a or 196b is shown at each site, the remote sites 132 and 142 may include multiple controllers and / or multiple communication points with the network 120.

[0018] The controllers 104, 196a, 196b may be operable to configure and manage network devices. For example, the controller 104 manages network devices at the primary site 102 and may also manage network devices at the remote sites 132, 134. The controllers 104, 196a, 196b may be operable to configure and / or manage switches, routers, access points, and / or client devices connected to the network. The controllers 104, 196a, 196b may themselves be access points or provide the functionality of an access point.

[0019] Controllers 104, 196a, 196b can communicate with other network devices. As shown, controller 104 can communicate with one or more switches 108 and / or wireless access points (APs) 106a-c. Switches 108 and wireless APs 106a-c provide network connectivity to various client devices 110a-j. Using connections to switches 108 or APs 106a-c, client devices 110a-j can access network resources, including the (primary site 102) network and other devices on network 120.

[0020] Examples of client devices (such as, 110a-110j) may include: desktop computers, laptop computers, servers, network servers, authentication servers, Authentication Authorization Accounting (AAA) servers, Domain Name System (DNS) servers, Dynamic Host Configuration Protocol (DHCP) servers, Internet Protocol (IP) servers, Virtual Private Network (VPN) servers, network policy servers, mainframes, tablet computers, e-readers, netbook computers, televisions and similar displays (e.g., smart TVs), content receivers, set-top boxes, personal digital assistants (PDAs), mobile phones, smart phones, smart terminals, dumb terminals, virtual terminals, video game consoles, virtual assistants, Internet of Things (IoT) devices, etc.

[0021] Within the primary site 102, a switch 108 is included as an example of an access point for wired client devices 110i-j to a network established within the primary site 102. The client devices 110i-j can connect to the switch 108 and, through the switch 108, can be able to access other devices within the network configuration 100. The client devices 110i-j may also be able to access a network 120 through the switch 108. The client devices 110i-j can communicate with the switch 108 via a wired 112 connection. In the example shown, the switch 108 communicates with the controller 104 via the wired 112 connection, although the connection can also be wireless.

[0022] Wireless APs 106a-c are included as another example of access points for the network established in the main site 102 for the client devices 110a-h. Each of the APs 106a-c can be a combination of hardware, software, and / or firmware configured to provide wireless network connectivity to the wireless client devices 110a-h. In the illustrated example, the APs 106a-c can be managed and configured by the controller 104. The APs 106a-c communicate with the controller 104 and the network via a connection 112 (which can be a wired or wireless interface).

[0023] also, Figure 1The AP 106a is shown as being configured to include: IPsec accelerator hardware 190, such as a co-processor specifically for offloading IPsec-related functions from the AP's CPU resources; IPsec accelerator software 191, such as dedicated processing software specifically for offloading IPsec-related functions from the AP's CPU resources; and an IPsec load balancer 195 that implements the IPsec SA balancing aspects disclosed herein to delegate IPsec functions between the IPsec accelerator hardware 190 and the IPsec accelerator software 191 in a manner that is optimally balanced based on the network deployment being used. As a general description, the IPsec SA load balancer 195 delegates processing to be performed related to establishing IPsec tunnels (e.g., encryption / decryption) between the IPsec accelerator software 191 (e.g., a software implementation of IPsec offloading) and the IPsec accelerator hardware 190 (e.g., a hardware implementation of IPsec offloading). Thus, an IPsec tunnel, such as the IPsec tunnel 197, can establish a secure VPN over an otherwise unsecured (e.g., public) network 120, such as the Internet. While Figure 1 The embodiments are described as establishing an IPsec tunnel with an AP, but it should be understood that the disclosed technology can be used to coordinate IPsec SAs and establish IPsec tunnels with any network point capable of supporting this functionality, such as gateways, branch gateways, and controllers connected via a Layer 3 network.

[0024] For context, IPsec describes a suite of security network protocol standards that uses cryptography to protect communications over Internet Protocol (IP) networks. It can be used to authenticate endpoint hosts and provide data confidentiality and integrity. IPsec can use the Internet Key Exchange (IKE) protocol to authenticate each peer in an IPsec session, negotiate security associations (SAs) between peers, and handle the exchange of session keys. IKE is the component of IPsec used to perform mutual authentication and establish and maintain SAs.

[0025] The IPsec data exchange between two peers can include five steps: i) initiation of an IPsec session; ii) IKE Phase 1; iii) IKE Phase 2; iv) data transfer; and v) IPsec session termination. IPsec session initiation (e.g., VPN tunnel) may be triggered when network traffic is marked for protection based on a certain IPsec security policy (SP) configured in the IPsec peers. For example, network traffic identified as a specific type can be marked for protection based on the security policy, while other traffic can travel normally over the public network. After the session is initiated, the IKE process can begin. In IKE Phase 1, the security parameters and keys required to establish an IKE security association (SA) can be negotiated. IKE Phase 1 may include: authenticating the identities of the IPsec peers; negotiating a common IKE SA policy between the peers to protect the IKE exchange; a Diffie-Hellman (DH) key exchange for creating a shared secret; and establishing a secure tunnel to negotiate IKE Phase 2 parameters.

[0026] During IKE Phase 2, the two peers can negotiate a shared IPsec policy and the security parameters and incoming / outgoing security keys required to establish two unidirectional IPsec SAs (e.g., one for incoming traffic and one for outgoing traffic). Traffic can then be exchanged during the IPsec session, with packets encrypted / decrypted at the peers using the encryption scheme specified in the IPsec SA. Furthermore, traffic can be authenticated.

[0027] The devices at either end of an IPsec tunnel are considered IPsec peers. Figure 1 , AP 106a and controller 196a, connected via IPsec tunnel 197, can be considered IPsec peers. To establish IPsec tunnel 197, IPsec peers (e.g., AP 106a and controller 196a) exchange a series of messages regarding encryption and authentication, and attempt to reach agreement on a number of different parameters during the VPN negotiation process, as described in detail above. One device of the IPsec peers operates as the initiator in the negotiation sequence, while the other device operates as the responder. As an example, AP 106a can be the initiator in the negotiation, while controller 196a acts as the responder.

[0028] IPsec SA load balancer 195 can be implemented as a combination of hardware, software, and / or firmware of an AP, such as AP 106a. IPsec SA load balancer 195 can be configured to selectively balance IPsec functions between IPsec hardware accelerator 190 and IPsec software accelerator 191. Furthermore, IPsec hardware accelerator 190 can be implemented as one or more hardware implementations, including but not limited to: an integrated circuit (IC) chip; a processor; a dedicated CPU (e.g., a core); and a coprocessor. Furthermore, IPsec software accelerator 191 can be implemented as one or more software implementations, including but not limited to: software module(s); an instruction set; an application; and firmware.

[0029] For example, IPsec SA load balancer 195 may determine to use IPsec accelerator hardware 190 to establish a defined number of IPsec tunnels (or, IPsec SAs), and then switch IPsec offload to IPsec accelerator software 191. IPsec accelerator software 191 may then be used to establish any additional number of IPsec tunnels (or, IPsec SAs), such as in a network that includes multiple heterogeneous controllers. IPsec SA load balancer 195 is configured to prioritize the use of IPsec hardware accelerator 190 and also prioritize establishing IPsec tunnels with certain controllers. For example, IPsec SA load balancer 195 may prioritize controllers with high performance requirements or controllers involved in IPsec data processing. Thus, by prioritizing the greater efficiency achieved by hardware-based IPsec offload (e.g., using IPsec hardware accelerator 190 until a maximum threshold of hardware resource constraints is reached), IPsec SA load balancer 195 may achieve improved utilization of IPsec capabilities of AP 106a.

[0030] The network configuration 100 may include one or more remote sites 132. The remote sites 132 may be located in a different physical or geographic location than the primary site 102. In some cases, the remote sites 132 may be located in the same geographic location as the primary site 102, or may be located in the same building, but lack a direct connection to the network located within the primary site 102. Instead, the remote sites 132 may utilize connections on different networks (e.g., network 120). Figure 1140d.

[0031] In various embodiments, the remote site 132 can communicate directly with the primary site 102, such that client devices 140a-d at the remote site 132 access network resources at the primary site 102 as if the client devices 140a-d were located at the primary site 102. In such embodiments, the remote site 132 is managed by the controller 104 at the primary site 102, and the controller 104 provides the necessary connectivity, security, and accessibility to enable the remote site 132 to communicate with the primary site 102. Once connected to the primary site 102, the remote site 132 can function as part of the private network provided by the primary site 102.

[0032] In various embodiments, the network configuration 100 may include one or more smaller remote sites 142 that include only a gateway device 144 for communicating with the network 120 and a wireless access point 146 for various client devices 150a-b to access the network 120. Such a remote site 142 may represent, for example, the home of an individual employee or a temporary remote office. The remote site 142 may also communicate with the main site 102, allowing client devices 150a-b at the remote site 142 to access network resources at the main site 102 as if the client devices 150a-150b were located at the main site 102. The remote site 142 may be managed by the controller 104 at the main site 102 to enable this transparency. Once connected to the main site 102, the remote site 142 may function as part of the private network provided by the main site 102.

[0033] The network 120 may be a public wide area network (WAN) such as the Internet, or other communication network for enabling connectivity between the various sites 102, 130 to 142 and access to the servers 160a-b. The network 120 may include third-party telecommunication lines such as telephone lines, broadcast coaxial cables, fiber optic cables, satellite communications, cellular communications, and the like. The network 120 may include any number of intermediate network devices, such as switches, routers, gateways, servers, and / or controllers, that are not directly part of the network configuration 100 but that facilitate communication between the various components of the network configuration 100 and between the network configuration 100 and other network-connected entities. The network 120 may include various content servers 160a-b. The content servers 160a-b may include various providers of multimedia downloadable and / or streaming content, including audio, video, graphics, and / or text content, or any combination thereof. Examples of content servers 160a-b include, for example, web servers, streaming broadcast and video providers, and cable and satellite television providers. Client devices 110a-j, 140a-d, 150a-b may request and access multimedia content provided by content servers 160a-b.

[0034] As an example, regarding Figure 1 , IPsec can be enabled in the network configuration 100 as a network layer security protocol. Figure 1 AP 106a is shown establishing IPsec tunnel 197 with controller 196a for secure communications. Therefore, AP 106a must perform additional processing to provide encryption and integrity protection for IPsec packets transmitted via IPsec tunnel 197. However, network configuration 100 may include a large number of controllers to provide connectivity, security, and accessibility to separate networks, such as remote sites 132 and 142. Consequently, in operation, AP 106a may need to simultaneously support multiple IPsec tunnels (e.g., individual IPsec tunnels for each controller) in order to provide secure communications to the controllers of the respective networks. As previously described, AP 196a enables IPsec hardware accelerator 190 and IPsec software accelerator 191 to establish an IPsec SA. For example, IPsec tunnel 197 may be among a set of IPsec tunnels (not shown) coordinated by AP 106a. Furthermore, after establishing IPsec tunnel 197, IPsec SA load balancer 195 may determine that AP 106a has now reached the limit on the number of IPsec tunnels that IPsec hardware accelerator 190 can support.

[0035] Continuing with this example, AP 106a may need to establish another IPsec tunnel with controller 196B for secure communications with remote site 142. However, if IPsec SA load balancer 195 knows that IPsec hardware accelerator 190 has reached its maximum resource limit, attempting to initiate any additional IPsec tunnels using hardware-based IPsec offload may be detrimental. A key aspect of the disclosed embodiments is the ability to switch an AP's IPsec offload between hardware and software implementations as deemed appropriate. In this example, IPsec SA load balancer 195 may begin utilizing AP 106a's IPsec software accelerator 191 to establish any subsequent IPsec SAs after IPsec hardware accelerator 190 has reached its maximum resource limit. Therefore, IPsec SA load balancer 195 may direct AP 106a to begin executing IPsec software accelerator 191 and establishing IPsec SAs with controller 196B. The IPsec tunnel to controller 196B will be supported by IPsec software accelerator 191, for example, using IPsec software accelerator 191 to perform encryption / decryption. The disclosed IPsec SA load balancing technology allows the APs in network configuration 100 to deploy IPsec in a multi-controller system in a flexible and customizable manner without violating and / or overextending the resource limitations of any one IPsec offload implementation. It should be understood that the implementations described herein need not be limited to Figure 1 . For example, in an enterprise environment, IPsec can be implemented to provide remote access VPNs to individual user devices, to provide intranet VPNs to connect to remote sites, and / or to provide extranet VPNs. According to the present disclosure, in the case of providing remote access VPN access to a user device (e.g., a user's laptop), the user device itself can include a VPN client configured to run an IPsec application, and it can function as an IPsec networking device.

[0036] Figure 2 An example environment 200 is shown in which the disclosed IPsec SA balancing techniques can be employed, particularly in a non-clustered multi-controller network configuration. Figure 2 Including the above reference Figure 1 Therefore, no detailed description will be given. Figure 22. The general structure and functionality of these elements in FIG. 2, such as controllers 240a-240f, AP 210, IPsec software accelerator 211, and IPsec hardware accelerator 212, are shown. In this example, AP 210 establishes secure communications with multiple controllers, as shown by controllers 240a-240f. Controllers 240a-240f are considered non-clustered because each of controllers 240a-240d may correspond to a separate network, as opposed to multiple controllers that are grouped together or clustered within the same site (e.g., FIG. 2. ). Figure 3 ).

[0037] In accordance with IPsec SA balancing techniques, as disclosed herein, AP 210 is configured to identify an IPsec priority corresponding to each of controllers 240a-240f. For illustrative purposes, the IPsec priority values described herein include high and low priorities. However, embodiments may employ various forms of priority designation, such as parameters, values, conditions, levels, ranges, and the like. In some embodiments, each controller 240a-240f has a previously assigned IPsec priority. For example, when a network is deployed and established, controllers 240a-240f may be assigned a low or high priority (e.g., by a network administrator). In some embodiments, the IPsec priority of each of controllers 240a-240f may be dynamically determined based on various network performance-related characteristics, such as traffic volume, airslice quality, and quality of service (QoS) requirements. For example, an IPsec priority may be assigned to a controller to improve the IPsec service performance of that controller, thereby improving voice or video quality. In some embodiments, IPsec priority may be determined using a combination of static and dynamic characteristics, as described above.

[0038] As an example, the IPsec priority of each of the controllers 240a-240f may be dynamically determined by the AP 210. For example, when traffic is transmitted between the AP 210 and the controllers 240a-240f, the AP 210 may determine whether any of the controllers 240a-240f is experiencing a volume of traffic that is considered "high traffic" (e.g., traffic above a threshold, traffic within a high traffic range, etc.). Figure 2In the example shown in FIG2 , AP 210 may determine that controllers 240a, 240c, and 240d are processing high traffic. AP 210 may then automatically assign a "high" IPsec priority to controllers 240a, 240c, and 240d. Conversely, AP 210 may determine whether any of controllers 240a-240f is experiencing a volume of traffic that is considered "low traffic" (e.g., traffic below a threshold, traffic within a low traffic range, etc.). For example, AP 210 identifies that controllers 240b, 240e, and 240f are experiencing low traffic and, therefore, may automatically assign a "low" IPsec priority to controllers 240b, 240e, and 240f.

[0039] AP 210 may be configured to offload the process of establishing IPsec SAs for “high” priority controllers to hardware IPsec accelerator 212. Conversely, if hardware IPsec accelerator 212 has reached its resource limits, AP 210 is configured to offload the process of establishing IPsec SAs for “low” priority controllers to software IPsec accelerator 211. According to this scheme, controllers 240a, 240c, and 240d that manage a larger percentage of network traffic (e.g., experiencing high traffic) will receive a more efficient IPsec offload implementation that supports higher throughput, namely, IPsec hardware accelerator 212. Additionally, AP 210 may determine that hardware IPsec software accelerator 212 has reached its resource limits for supporting IPsec tunnels 220a-220c. AP 210 may then switch to using IPsec software accelerator 211. Consequently, controllers 240b, 240e, and 240f that handle less traffic on the network (e.g., experiencing low traffic) will use IPsec software accelerator 212 to coordinate their IPsec SAs. According to this scheme, Figure 2 It is shown that AP 210 has: established IPsec tunnel 220a with controller 240a, IPsec tunnel 220b with controller 240c, and IPsec tunnel 220c with controller 240d via hardware IPsec accelerator 212; and established IPsec tunnel 230a with controller 240b, IPsec tunnel 230b with controller 240e, and IPsec tunnel 230c with controller 2404 via software IPsec accelerator 211.

[0040] There may be situations where AP 210 can offload IPsec SAs for all controllers in a deployment with high IPsec priorities without reaching hardware resource limits. In such situations, AP 210 is configured to continue using IPsec hardware accelerator 212 to establish IPsec SAs even for controllers assigned low IPsec priorities. In other words, AP 210 does not switch IPsec offload to a software-based implementation until the hardware-based implementation is fully utilized.

[0041] Now refer to Figure 3 , depicts an example of another environment 300, particularly a clustered multi-controller network configuration, in which the disclosed IPsec SA balancing techniques can be employed. Figure 3 Including the above reference Figure 1 Therefore, no detailed description will be given. Figure 3 3. The general structure and functions of these elements in the present invention are described, such as controller 340, AP 310, IPsec software accelerator 311, and IPsec hardware accelerator 312. In particular, in this example, there are multiple controllers 340, which are grouped together into corresponding clusters 350a-350d. That is, each of the clusters 350a-350d includes a grouping of several controllers 340 distributed therein. For example, each of the clusters 350a-350d can be a group of controllers 340 located at the same network site. As an example, each of the clusters 350a-350d can be arranged on a corresponding local area network (LAN). In addition, the AP 310 has secure communications established with multiple controllers 340 within each of the clusters 350a-350d. Figure 3 FIG3 shows that in a clustered multi-controller environment 300, AP 310 balances all IPsec client traffic within a cluster. Therefore, AP 310 will establish the same type of IPsec tunnels established by IPsec software accelerator 311 or IPsec hardware accelerator 312 for all controllers 340 within one of the corresponding clusters 350a-350d. For example, Figure 3 As shown in FIG, multiple IPsec tunnels 320 a, 320 b from AP 310 to clusters 350 a, 350 c, respectively, are coordinated via hardware-based IPsec offload and supported using IPsec hardware accelerator 312. Multiple IPsec tunnels 330 a, 330 b from AP 310 to clusters 350 b, 350 d, respectively, are coordinated via software-based IPsec offload and supported using IPsec software accelerator 312.

[0042] In the clustered multi-controller environment 300, the AP 310 may be configured to identify the IPsec priority associated with each of the clusters 350a-350d, rather than Figure 2 Each of the clusters 350a-350d may have an IPsec priority previously defined or referenced by AP 310. Figure 2 The corresponding IPsec priorities are dynamically determined in the same manner as described in detail above. As an example, AP 310 may identify clusters 350a, 350c as having a "high" IPsec priority (e.g., experiencing a volume of traffic that is considered "high traffic"). Additionally, AP 310 may identify clusters 350b, 350d as having a "low" IPsec priority (e.g., experiencing a volume of traffic that is considered "high traffic").

[0043] As a result, AP 310 establishes IPsec SAs for all controllers 340 on the "high" priority clusters 350a and 350c using hardware IPsec accelerator 212. Alternatively, when the resource constraints of hardware IPsec accelerator 212 are met, AP 310 may establish IPsec SAs for all controllers 340 on the "low" priority clusters 350b and 350d using software IPsec accelerator 211.

[0044] According to an embodiment, one aspect of the IPsec SA balancing technique includes proactively "upgrading" a connection for a controller from an IPsec tunnel supported using software-based IPsec offloading to an IPsec tunnel supported using hardware-based IPsec offloading. As described above, a hardware-based IPsec offloading implementation can have advantages (in terms of processing efficiency) over a software-based IPsec offloading implementation. Due to these advantages (such as increased throughput), IPsec tunnels coordinated using an IPsec hardware accelerator can provide better service performance (compared to a software-based IPsec offloading implementation). To this end, Figure 4 AP 410 is shown configured to perform the disclosed "upgrade" feature of IPsec SA balancing. Figure 4 Including the above reference Figure 1 In particular, Figure 4 AP 410 is depicted, and AP 410 includes Figure 1 The IPsec SA load balancer 195, IPsec software accelerator 190 and IPsec hardware accelerator 191 are described in detail in FIG.

[0045] There are various situations where it may be optimal to "upgrade" a controller initially supporting IPsec tunnels via IPsec software accelerator 190 to IPsec tunnels supported via IPsec hardware accelerator 191. As an example, AP 410 may need to coordinate IPsec SAs for a controller with a "high" IPsec priority. However, IPsec hardware accelerator 191 may be approaching the number of IPsec tunnels it can support based on its resource limitations. In another example, IPsec hardware accelerator 191 may have reached its resource limitations. However, a controller currently using IPsec tunnels supported by IPsec software accelerator 190 may need to "upgrade" to IPsec tunnels supported by IPsec hardware accelerator 191, for example because the controller is now experiencing high traffic, is now supporting traffic associated with higher QoS requirements, or other conditions that may be related to IPsec priority as described above. As a general description, in these situations, AP 410 may "downgrade" a controller with IPsec tunnels supported by a hardware-based IPsec offload implementation, despite having a "low" IPsec priority. Then, subsequently, AP 410 may "upgrade" the controller with IPsec tunnels supported by the software-based IPsec offload implementation, albeit with a "high" IPsec priority.

[0046] In particular, Figure 4 IPsec SA load balancer 195, shown implemented on AP 410, may include several internal components, including, but not limited to: a tunnel traffic monitor 416; a quality of service monitor 417; a configuration module 418; a user application 413; an IPsec tunnel manager 414 that manages IPsec tunnels established and supported by AP 410; and a kernel 415 that facilitates command and / or control communications between IPsec tunnel manager 414, IPsec software accelerator 190, and IPsec hardware accelerator 191. These components of IPsec SA load balancer 195 may be implemented as hardware, software, firmware, or a combination thereof.

[0047] Thus, AP 410 has the ability to determine whether controllers 440a, 440b are experiencing conditions, such as QOS or high traffic volume, that would trigger the disclosed "upgrade" scenario. In operation, AP 410 may initially establish IPsec tunnel 430a for controller 440a using IPsec software accelerator 190. Furthermore, AP 410 previously established IPsec tunnel 420a for controller 440b using IPsec hardware accelerator 191, while controller 440b was identified as having "low" IPsec priority. Subsequently, AP 410 may determine that IPsec hardware accelerator 191 has reached its resource-limited maximum number of IPsec tunnels. AP 410 may also determine that controller 440a is now experiencing high traffic, for example, using tunnel traffic monitor 416, and therefore needs to "upgrade" from its current software-supported IPsec tunnel 430a to a hardware-supported IPsec tunnel to ensure good performance for this higher volume of traffic being handled by controller 440a.

[0048] AP 410 has the ability to examine the configuration of the IPsec SA balance being used (e.g., IPsec tunnel type, IPsec tunnel end nodes, etc.). Based on this configuration, AP 410 can further detect which controller(s) have a "low" IPsec priority and also have IPsec tunnels established using a hardware IPsec offload implementation, in order to "downgrade" one or more of these controllers to a secondary or "backup" IPsec tunnel established using a software IPsec offload implementation. In this example, AP 410 can detect that controller 440b has a "low" IPsec priority but is using IPsec tunnel 420a supported using IPsec hardware accelerator 190. In response, AP 410 can "downgrade" controller 440b by establishing a second IPsec tunnel 430b as a backup IPsec tunnel to controller 440b. The IPsec SA for backup IPsec tunnel 430b is coordinated by IPsec software accelerator 191. After successfully establishing backup IPsec tunnel 430b, traffic can begin flowing through backup IPsec tunnel 430b instead of initial IPsec tunnel 420a. Since controller 440b is not actively using IPsec tunnel 420a, AP 410 can then terminate IPsec tunnel 420, releasing the IPsec SA in IPsec hardware accelerator 190. When its IPsec SA is terminated by deletion (or by timeout), the IPsec tunnel is closed. Therefore, by releasing the IPsec tunnel, IPsec hardware accelerator 190 operates below its resource limits and has the processing power to support subsequent IPsec SAs.

[0049] Subsequently, AP 410 may establish IPsec tunnel 420b as a backup IPsec tunnel for controller 440a using IPsec hardware accelerator 190. AP 410 closes the previous IPsec tunnel 430a established by IPsec software accelerator 191 to allow controller 440a, which has a "high" IPsec priority, to now transmit its traffic via IPsec tunnel 430b to improve performance. Figure 4 The IPsec "upgrade" aspect of the disclosed IPsec SA balancing technique shown in can be suitable for scenarios where the CPU load on the AP is not high. Alternatively, when the CPU load at the AP is high (which is not conducive to software-based IPsec offload implementations that rely on consuming CPU resources), another IPsec SA loading scheme involving dedicated and shared hardware encryption channels can be adopted, such as Figure 5 As shown in .

[0050] Figure 5 An example of an AP 510 implementing multiple channels is depicted, which command and / or control data sent to IPsec offload hardware, such as an IPsec hardware accelerator (not shown), for processing. In the illustrated example, the AP 510 includes dedicated hardware channels 560a and 560b and a shared hardware channel 550. The AP 510 is configured to assign IPsec SAs to traffic based on the characteristics of the controller and / or IPsec tunnel. For example, if the AP 510 determines that an IPsec tunnel is handling a high traffic load, it will assign a dedicated hardware encryption channel to the IPsec tunnel. Figure 5 Dedicated hardware channel 560b is shown for IPsec tunnel 520d to controller 540d, and dedicated hardware channel 560a is shown for IPsec tunnel 520c to controller 540c. In other words, dedicated hardware channels 560a and 560b are each configured to process data for one IPsec tunnel and one controller, respectively, so that the IPsec hardware accelerator processes the corresponding IPsec SA.

[0051] Furthermore, AP 510 includes a shared hardware cryptographic channel 550 shared by multiple IPsec tunnels 520a and 520b to controllers 540a and 540b, respectively. Regarding the shared hardware cryptographic channel 550, AP 510 (an IPsec tunnel manager using an IPsec SA load balancer) can apply a queue 570 to appropriately process traffic corresponding to controllers 540a and 540b, both of which use the shared hardware cryptographic channel 550. Consequently, based on the scheduling scheme of queue 570 (e.g., first-in-first-out (FIFO) or last-in-first-out (LIFO)), hardware (such as an IPsec hardware accelerator) will switch to begin processing traffic / IPsec SAs of IPsec tunnels communicated from queue 570. For example, queue 570 may first output traffic 580b of IPsec tunnel 520b. Consequently, the hardware processes the IPsec SA to enable the shared cryptographic channel 550 for secure transmission of traffic 580b to controller 540b via IPsec tunnel 520b. Then, queue 570 may switch to begin outputting traffic 580a for IPsec tunnel 520a. As a result, shared cryptographic channel 550 will be enabled to transmit traffic 580a to controller 540a via IPsec tunnel 520a. Figure 5 The IPsec SA loading technique shown in can utilize hardware channels to allow sharing of IPsec hardware accelerators, such as by switching between different controllers, to achieve more efficient traffic processing (eg, reducing the amount of software-based IPsec offload used).

[0052] Figure 6 6 is an operational flow diagram illustrating an example method 600 for implementing an IPsec SA balancing scheme as disclosed herein. The process 600 is illustrated as a series of executable operations performed by a hardware processor 602 in a machine-readable storage medium 601. The computing component 603 may be a computer device that is an IPsec networking device, such as an AP (e.g., Figure 1 ), as previously described.

[0053] In one example, an IPsec peer may wish to authenticate and initiate a secure connection over the network by initiating an IPsec data exchange to establish a connection including a secure IPsec tunnel. As part of the IPsec data exchange process, incoming and outgoing security keys and IPsec SAs may be initialized and updated over time. IPsec networking devices (such as access points) may transparently process and route information according to the IPsec protocol. Thus, IPsec can be used to build a virtual private network (VPN) for a remote site across a network that may be a public network (e.g., the Internet).

[0054] Process 600 may be initiated at operation 610. The initiation of an IPsec session involving the establishment of an IPsec tunnel may be triggered by network traffic. For example, a specific type of traffic transmitted to a controller may be marked for protection. In order to execute the initiated IPsec session, the IPsec network device begins processing to perform IPsec-related functions. For example, it is necessary to configure and establish an IPsec tunnel between IPsec peers for the IPsec session. In addition, there are encryption / decryption functions, as well as negotiation of keys and other parameters for all IPsec SAs involved in the IPsec session. Therefore, after the IPsec session is initiated, process 600 may continue to operation 615 to ultimately offload the IPsec processing to a software-based IPsec accelerator or a hardware-based IPsec accelerator.

[0055] As previously mentioned, an IPsec network device (such as an AP) can be enabled using both an IPsec hardware accelerator and an IPsec software accelerator. Furthermore, depending on one of the IPsec SA loading schemes, the use of an IPsec hardware accelerator may take precedence over the use of an IPsec software accelerator. In other words, process 600 utilizes the IPsec hardware accelerator until it is deemed potentially decisive, such as by reaching hardware resource limits. Therefore, in operation 615, the IPsec network device performs a conditional check to determine whether the IPsec hardware accelerator has reached its resource limits. For example, the IPsec hardware accelerator may have design features that limit the hardware from supporting a certain number of IPsec tunnels simultaneously. Consequently, operation 615 may include detecting the current number of IPsec tunnels established and / or supported by the IPsec hardware accelerator. While operation 615 is discussed with respect to the number of active IPsec tunnels, other forms of comparison, checking, and calculation may be performed to determine whether the IPsec hardware accelerator's resource limits (e.g., CPU cycle cost, CPU processing cost, latency, etc.) have been reached. These resource limits are not described in detail for the sake of brevity.

[0056] Where the current number of IPsec tunnels is less than the number of IPsec tunnels permitted by the IPsec hardware accelerator resource limit, this indicates that the hardware is operating below its available capacity and has not yet reached and / or exceeded the resource limit (in Figure 6(shown as "No" in the example). Therefore, process 600 can continue to use the IPsec hardware accelerator without the risk of negatively impacting IPsec performance by operating beyond hardware limitations. Thereafter, process 600 proceeds to operation 625. At operation 625, the IPsec networking device can offload IPsec SA-related processing for the initiated IPsec session to the IPsec hardware accelerator. Subsequently, the IPsec session between the IPsec peers (i.e., the AP and the controller) can proceed to provide secure communications over the network.

[0057] Referring again to operation 615, the IPsec network device may alternatively determine that the current number of IPsec tunnels is equal to and / or greater than the number of IPsec tunnels permitted by the IPsec hardware accelerator resource limit. In this case, the result of operation 615 indicates that the hardware is operating at (or above) its available capacity and has reached and / or exceeded the resource limit (at Figure 6 ( 'Yes' is shown in the example). Therefore, process 600 determines that continued use of the IPsec hardware accelerator may exceed the hardware's capabilities and significantly increase the likelihood of negatively impacting IPsec processing. In this situation, it may be beneficial to utilize an IPsec software accelerator, also enabled on the IPsec networking device. As described above, the IPsec software accelerator continues to utilize the host's CPU resources in the same manner as a hardware-based implementation, but is not limited to, for example, a certain number of IPsec tunnels. Therefore, the IPsec software accelerator offers the advantage of flexibility in larger-scale systems. Therefore, process 600 continues to operation 620 to utilize the IPsec software accelerator.

[0058] At operation 620, to establish the initiated IPsec session, the IPsec networking device switches from the IPsec hardware accelerator and offloads the processing of the IPsec SA to the IPsec software accelerator. Any previously established IPsec SAs (and IPsec tunnels) configured by the IPsec hardware accelerator can continue to operate using the IPsec hardware accelerator. Therefore, process 600 does not incur any additional overhead associated with switching an already active IPsec session between software and hardware implementations. Instead, operation 620 is offloaded to the IPsec software accelerator to coordinate the IPsec SA specifically for the currently initiated IPsec session. Subsequently, the IPsec session between the IPsec peers (i.e., the AP and the controller) can proceed to provide secure communications over the network.

[0059] Figure 7A block diagram of an example computer system 700 is depicted in which the IPsec SA loading techniques described herein may be implemented. For example, the computer system 700 may be an IPsec networking device, such as an AP ( Figure 1 ), as described in detail above. Computer system 700 includes a fabric 702 or other communication mechanism for transmitting information, and one or more hardware processors 704 coupled to fabric 702 for processing information. Hardware processor(s) 704 may be, for example, one or more general-purpose microprocessors.

[0060] The computer system 700 also includes a main memory 706, such as a random access memory (RAM), a cache, and / or other dynamic storage device, coupled to the structure 702 for storing information and instructions to be executed by the processor 704. The memory 706 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 704. Such instructions, when stored in a storage medium accessible to the processor 704, present the computer system 700 as a special-purpose machine that is customized to perform the operations specified in the instructions.

[0061] Computer system 700 also includes a storage device 710, such as a read-only memory (ROM) or other static storage device coupled to fabric 702 for storing static information and instructions for processor 704. A storage device 710, such as a magnetic disk, an optical disk, or a USB thumb drive (flash drive), is provided and coupled to fabric 702 for storing information and instructions.

[0062] The computer system 700 can be coupled to a display 712, such as a liquid crystal display (LCD) (or alternatively, a touch screen), via structure 702 for displaying information to a computer user. An input device 714, including alphanumeric and other keys, is coupled to the structure 702 for communicating information and command selections to the processor 704. Another type of user input device is a cursor control 716, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 704 and for controlling cursor movement on the display 712. In some embodiments, the same direction information and command selections as those of a cursor control can be achieved by receiving touches on a touch screen without a cursor.

[0063] The computing system 700 may include a user interface module to implement a GUI, which may be stored in a mass storage device as executable software code executed by the computing device(s). By way of example, this module and other modules may include components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

[0064] In general, as used herein, the terms "component," "engine," "system," "database," "data store," and the like may refer to logic embodied in hardware or firmware, or to a set of software instructions, possibly with entry and exit points, written in a programming language such as Java, C, or C++. Software components may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as BASIC, Perl, or Python. It should be understood that software components may be called from other components or themselves, and / or may be called in response to detected events or interrupts. Software components configured for execution on a computing device may be provided on a computer-readable medium, such as an optical disc, digital video disc, flash drive, magnetic disk, or any other tangible medium, or as a digital download (and may be initially stored in a compressed or installable format that requires installation, decompression, or decryption prior to execution). Such software code may be stored in part or in whole on a memory device of the executing computing device for execution by the computing device. The software instructions may be embedded in firmware, such as an EPROM. It will also be understood that hardware components may include connected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0065] The computer system 700 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, causes the computer system 700 to become or be programmed to function as a special-purpose machine. According to one embodiment, the techniques herein are performed by the computer system 700 in response to the processor(s) 704 executing one or more sequences of one or more instructions contained in the main memory 706. These instructions can be read into the main memory 706 from another storage medium, such as the storage device 710. Execution of the sequences of instructions contained in the main memory 706 causes the processor(s) 704 to perform the process steps described herein. In alternative embodiments, hardwired circuitry can be used in place of or in combination with software instructions.

[0066] As used herein, any form of hardware, software or its combination can be utilized to realize circuit.For example, one or more processors, controllers, ASIC, PLA, PAL, CPLD, FPGA, logic components, software routines or other mechanisms can be realized to form circuit.In realization, various circuits described herein can be realized as discrete circuits, or described functions and features can be partially or entirely shared between one or more circuits.Even if various features or elements of function can be described or claimed separately as independent circuits, these features and functions also can be shared between one or more common circuits, and such description should not require or imply that independent circuits are needed to realize such features or functions.When circuit is realized in whole or in part using software, such software can be realized to operate together with the computing or processing system (such as, computer system 700) that can perform the function described about it.

[0067] As used herein, the term "or" may be interpreted as inclusive or exclusive. Furthermore, descriptions of resources, operations, or structures in the singular should not be interpreted as excluding the plural. Unless expressly stated otherwise or otherwise understood in the context of use, conditional language such as "may," "could," "might," or "might" is generally intended to convey that certain embodiments include and other embodiments do not include certain features, elements, and / or steps.

[0068] Unless expressly stated otherwise, the terms and phrases used in this document and variations thereof should be interpreted as open-ended and non-restrictive. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the items described to a given time period or to items available as of a given time, but should be understood to include conventional, traditional, normal, or standard technology that may be available or known at any time now or in the future. In some instances, the presence of phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be understood to indicate that a narrower instance is intended or required where such broadening words may not be present.

Claims

1. A method for load balancing, comprising: An IPsec session is initiated by an Internet Protocol security (IPsec) networking device; determining, by the IPsec networking device, whether a resource limit for a hardware-based IPsec accelerator has been reached, wherein the hardware-based IPsec accelerator is enabled on the IPsec networking device; and in response to determining that the resource limit for the hardware-based IPsec accelerator has been reached, offloading, by the IPsec networking device, processing of an IPsec security association (SA) associated with the initiated IPsec session to a software-based IPsec accelerator enabled on the IPsec networking device, wherein offloading the processing for the IPsec SA to the software-based IPsec accelerator comprises establishing an IPsec tunnel between the IPsec networking device and a controller of a multi-controller system using the software-based IPsec accelerator, and Wherein determining whether the resource limit for the hardware-based IPsec accelerator has been reached comprises: determining a current number of IPsec tunnels established by the hardware-based IPsec accelerator; comparing the current number of IPsec tunnels to a maximum number of IPsec tunnels corresponding to the resource limit of the hardware-based IPsec accelerator; and In response to determining that the current number of IPsec tunnels has reached or exceeded the maximum number of IPsec tunnels, it is determined that the resource limit for the hardware-based IPsec accelerator has been reached.

2. A system for load balancing, comprising: Multiple controllers; Communication networks; an Internet Protocol security (IPsec) networking device communicatively connected to the plurality of controllers via the communications network and comprising a machine-readable storage medium comprising instructions executable by the IPsec networking device to: initiating an Internet Protocol security (IPsec) session with a first controller among the plurality of controllers; determining whether resource limits for a hardware-based IPsec accelerator have been reached; In response to determining that the limit for the hardware-based IPsec accelerator has been reached, establishing an initial IPsec SA for the first controller corresponding to the initiated IPsec session using a software-based IPsec accelerator; In response to determining that the resource limit for the hardware-based IPsec accelerator has been reached, and determining that the initiated IPsec session is associated with the first controller having a high IPsec priority; identifying a second controller of the plurality of controllers that is associated with a low IPsec priority, The hardware-based IPsec accelerator establishes an initial IPsec security association SA corresponding to the second controller, wherein the establishment of the initial IPsec SA includes establishing an initial IPsec tunnel to the second controller. establishing a secondary IPsec SA for the second controller using a software-based IPsec accelerator, wherein establishing the secondary IPsec SA includes establishing a secondary IPsec tunnel to the second controller; transmitting traffic corresponding to the second controller using the secondary IPsec tunnel to the second controller; as well as The initial IPsec tunnel is terminated to the second controller.

3. The system of claim 2 , wherein the instructions comprise instructions executable by the IPsec networking device to: A secondary IPsec SA is established with the first controller using the hardware-based IPsec accelerator.

4. The system of claim 3, wherein the instructions include instructions executable by the IPsec networking device to: A secondary IPsec tunnel is established by the hardware-based IPsec accelerator to the first controller corresponding to the secondary IPsec SA for the first controller.

5. The system of claim 4, wherein the instructions include instructions executable by the IPsec networking device to: terminating an initial IPsec tunnel to the first controller corresponding to the initial IPsec SA for the first controller; and Traffic corresponding to the initiated IPsec session is transmitted using the secondary IPsec tunnel to the first controller.

6. The system of claim 2, wherein an IPsec priority associated with the first controller corresponding to the initiated IPsec session is adjusted from a low IPsec priority to a high IPsec priority.

7. The system of claim 2, wherein the IPsec networking device comprises an access point (AP).

8. The system of claim 7, wherein the hardware-based IPsec accelerator and the software-based IPsec accelerator are enabled on the AP.

9. The system of claim 2, wherein the instructions to determine whether the resource limit for the hardware-based IPsec accelerator has been reached include instructions executable to: determining a current number of IPsec tunnels established by the hardware-based IPsec accelerator; comparing the current number of IPsec tunnels to a maximum number of IPsec tunnels corresponding to the resource limit of the hardware-based IPsec accelerator; as well as In response to determining that the current number of IPsec tunnels has reached or exceeded the maximum number of IPsec tunnels, it is determined that the resource limit for the hardware-based IPsec accelerator has been reached.

10. A non-transitory computer-readable storage medium comprising instructions executable by a processor of an Internet Protocol security (IPsec) networking device to: Initiate an IPsec session; determining whether resource limits for a hardware-based IPsec accelerator have been reached; identifying an IPsec priority associated with a controller of an IPsec tunnel to be established between the IPsec networking device and the controller of a multi-controller system; as well as In response to determining that the IPsec priority associated with the controller is low and determining that the resource limit for the hardware-based IPsec accelerator has not been reached: offloading processing of an IPsec security association (SA) associated with the initiated IPsec session to the hardware-based IPsec accelerator; and In response to determining that the resource limit for the hardware-based IPsec accelerator has been reached: offloading the processing of the IPsec SA associated with the initiated IPsec session to a software-based IPsec accelerator; Wherein offloading the processing for the IPsec SA to the software-based IPsec accelerator includes establishing the IPsec tunnel between the IPsec networking device and the controller using the software-based IPsec accelerator.

11. The non-transitory computer-readable storage medium of claim 10, the instructions comprising instructions executable by the processor of the IPsec networking device to: In response to determining that the IPsec priority associated with the controller is high and determining that the resource limit for the hardware-based IPsec accelerator has not been reached: Processing of the IPsec SA associated with the initiated IPsec session is offloaded to the hardware-based IPsec accelerator.

12. The non-transitory computer-readable storage medium of claim 11 , wherein offloading the processing for the IPsec SA to the hardware-based IPsec accelerator comprises establishing an IPsec tunnel between the IPsec networking device and a controller of a multi-controller system using the hardware-based IPsec accelerator.

13. The non-transitory computer-readable storage medium of claim 10, wherein the IPsec priority is determined by the IPsec networking device based on at least one of: Traffic volume, traffic type, and quality of service (QOS) associated with the controller for the IPsec session.

14. The non-transitory computer-readable storage medium of claim 10, wherein the IPsec priority is assigned to the controller of the multi-controller system.

15. The non-transitory computer-readable storage medium of claim 10, wherein: The controller is one of a plurality of controllers in a cluster of controllers in the multi-controller system; and The IPsec priority is assigned to the cluster including the controller.

16. The non-transitory computer-readable storage medium of claim 10, wherein instructions to determine whether the resource limit for the hardware-based IPsec accelerator has been reached include instructions to: determining a current number of IPsec tunnels established by the hardware-based IPsec accelerator; comparing the current number of IPsec tunnels to a maximum number of IPsec tunnels corresponding to the resource limit of the hardware-based IPsec accelerator; as well as In response to determining that the current number of IPsec tunnels has reached or exceeded the maximum number of IPsec tunnels, it is determined that the resource limit for the hardware-based IPsec accelerator has been reached.

Images