System and method for achieving hardware acceleration for asymmetric flow connections

Abstract

Performance of connection flow management between a hardware-based network interface and a software module of a network traffic management device is disclosed. A flow connection setup for a flow connection is established between a client device and a server at the network traffic management device. It is then determined if the flow connection is symmetrical or asymmetrical in nature. A flow signature entry and a transformation data entry for the flow connection is generated, by software executed by the network traffic management device, in opposing first and second symmetric or asymmetric flow directions. The flow signature entry and the transformation data entry for the first and second flow directions is sent from the software module to the network interface. The network interface stores and utilizes the flow signature entry and the transformation data entry to perform acceleration on data packets in the first and second flow directions.

Description

FIELD

This technology generally relates to managing network traffic in a virtual bladed chassis, and more particularly, to a system and method for achieving hardware acceleration for asymmetric flow connections.

BACKGROUND

The Internet's core bandwidth continues to double every year. Some of this additional bandwidth is consumed as more and more users access the Internet. Other additional bandwidth is consumed as existing users increase their use of the Internet. This increase of Internet use translates into an increase in traffic directed to and from World Wide Web servers (“Web servers”).

Replacing a Web server with another Web server having twice the capacity is a costly undertaking, whereas merely adding the new Web server(s) is less costly but usually requires a load-balancing mechanism to balance workload so that each virtual server performs work proportional to its capacity. Network traffic management devices positioned between client devices and the Web servers typically handle the load balancing functions, which typically more processing of data packets communicated between the client devices and Web servers. With increasing traffic, the network traffic management device will eventually not be able to process traffic in a timely manner.

For software assisted hardware acceleration, at connection establishment, a software module may push connection flow signature and transformation data to a hardware device to perform acceleration on the flow. The flow signature and transformation data is typically pushed in a single transaction in which the signature and transformation data is embedded with the flow header and data. Accordingly, two flow signature and transformation entries may be created accordingly. This approach incorrectly assumes that these two flows are symmetric and are reversible. However, for an asymmetric flow connection, the client-to-server and server-to-client flows have different flow signature and transformation information. Therefore, the flow may be accelerated in one direction while the flow in the other direction may not be properly accelerated.

What is needed is a system and method for achieving hardware acceleration for asymmetric flow connections.

SUMMARY

In an aspect, a method for performing connection flow management between a hardware device and a software module is disclosed. The method comprises establishing, at a network traffic management device having a software module and a hardware acceleration device, a flow connection setup for a flow connection between a client device and a server. The method comprises determining if the flow connection is symmetrical or asymmetrical in nature. The method comprises generating, at the software module, a flow signature entry and a transformation data entry for the flow connection in the first flow direction and a second flow direction opposite to the first flow direction, wherein the first and second flow directions are capable of being either symmetric or asymmetric in nature. The method comprises sending the flow signature entry and the transformation data entry for the first and second flow directions from the software module to the hardware acceleration device, wherein the hardware acceleration device at least stores the flow signature entry and the transformation data entry for the first and second flow directions, the hardware acceleration device configured to utilize the flow signature entry and the transformation data entry to perform acceleration on data packets in the first and second flow directions.

In an aspect, a non-transitory computer readable medium having stored computer executable code thereon in form of instructions for connection flow management to be performed by a network traffic management device is disclosed. The network traffic management device executes the code which causes at least a portion of the network traffic management device to perform a method. The method comprises establishing, at a hardware acceleration device of a network traffic management device, a flow connection setup for a flow connection to be handled by the network traffic management device between a client device and a server. The method comprises determining if the flow connection is symmetrical or asymmetrical in nature. The method comprises generating, at the software module, a flow signature entry and a transformation data entry for the flow connection in the first flow direction and a second flow direction opposite to the first flow direction, wherein the first and second flow directions are capable of being either symmetric or asymmetric in nature. The method comprises sending the flow signature entry and the transformation data entry for the first and second flow directions from the software module to the hardware acceleration device, wherein the hardware acceleration device at least stores the flow signature entry and the transformation data entry for the first and second flow directions, the hardware acceleration device configured to utilize the flow signature entry and the transformation data entry to perform acceleration on data packets in both first and second flow directions.

In an aspect, a network traffic management device is disclosed. The device comprises a memory stored thereon machine executable code comprising instructions for performing connection flow management. The device comprises a hardware-based network interface controller coupled to the memory and capable of receiving and forwarding data packets over a network that relate to a plurality of applications. The network interface controller configured to establish a flow connection setup for a flow connection between a client device and a server via the network traffic management device and operate as an acceleration device. The device includes a processor operably coupled with the memory and the network interface controller. The processor is configured to execute programmed instructions stored in the memory which causes the network traffic management device to perform a method. The method comprises determining if the flow connection is symmetrical or asymmetrical in nature. The method comprises generating a flow signature entry and a transformation data entry for the flow connection in the first flow direction and a second flow direction opposite to the first flow direction, wherein the first and second flow directions are capable of being either symmetric or asymmetric in nature. The method comprises sending the flow signature entry and the transformation data entry for the first and second flow directions to the network interface controller. The network interface controller at least stores the flow signature entry and the transformation data entry for the first and second flow directions. The network interface controller is configured to utilize the flow signature entry and the transformation data entry to perform acceleration on data packets in both of the first and second flow directions.

In one or more of the above aspects, the method performed by the network traffic management device further comprises generating a flow creation message, wherein the flow creation message includes information associated with a flow type, actual data or pass flow information associated with the flow connection.

In one or more of the above aspects, the method performed by the network traffic management device further comprises updating the flow signature entry and the transformation data entry for the flow connection.

In one or more of the above aspects, the network interface controller is a high speed bridge.

In one or more of the above aspects, the method performed by the network traffic management device further comprises receiving, at the network interface controller, the flow signature and the transformation data entry; and storing the flow signature and the transformation data entry in a flow table in the memory.

In one or more of the above aspects, the method performed by the network traffic management device further comprises identifying a first flow connection associated with the received data packets; and accessing the memory to determine if the first flow connection is in a flow table. In one or more of the above aspects, method performed further comprises forwarding the data packets to a DMA when the first flow connection is not in the flow table.

In one or more of the above aspects, the method performed by the network traffic management device further comprises retrieving a first flow signature entry and a first transform information entry associated with the first flow connection; and transforming and multiplexing the data packets of the first flow connection into a transmit data path.

In one or more of the above aspects, the method performed by the network traffic management device further comprises determining that the flow connection employs a Direct Server Return (DSR) load balancing operation between the server and the client, wherein a response from the server is not received at the network traffic management device. The flow signature entry and the transform information entry is provided by the processor to the network interface to perform acceleration only on data packets traveling in one or more flow segments sent in a flow direction from the client device and the server.

In one or more of the above aspects, the method performed by the network traffic management device further comprises determining that the flow connection between the network traffic management device and the server is reused for multiple requests from one or more client devices and providing the flow signature entry and the transform information entry to the network interface to perform hardware acceleration only on data packets in one or more flow segments between the client device and the network traffic management device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary network system environment using a virtualized network traffic management system in accordance with an aspect of the present disclosure;

FIG. 2A is a block diagram of a network traffic management device in accordance with an aspect of the present disclosure;

FIG. 2B is a block diagram of a network traffic management system with multiple network traffic management devices capable of operating in full virtualization mode in accordance with an aspect of the present disclosure;

FIG. 2C is a ladder diagram illustrating flow directions associated with a flow connection in accordance with an aspect of the present disclosure;

FIG. 3A is a flowchart of an exemplary process and method performed by the network traffic management device in accordance with an aspect of the present disclosure;

FIG. 3B is a flowchart of an exemplary process and method performed by the network traffic management device in accordance with an aspect of the present disclosure;

FIG. 4 illustrates a block diagram of the high speed bridge (HSB) in accordance with an aspect of the present disclosure;

FIG. 5 illustrates a functional diagram of the HSB operating in conjunction with at least one processor in accordance with an aspect of the present disclosure;

FIG. 6A illustrates an example HSB single flow snoop header in accordance with an aspect of the present disclosure;

FIG. 6B illustrates an example HSB double flow snoop header in accordance with an aspect of the present disclosure;

FIG. 7 illustrates an exemplary HSB Flow Cache table entry in accordance with an aspect of the present disclosure; and

FIG. 8 illustrates an exemplary HSB Teardown descriptor in accordance with an aspect of the present disclosure.

DETAILED DESCRIPTION

FIG. 1 illustrates an exemplary network system environment using one or more virtualized network traffic management apparatus for achieving hardware acceleration for asymmetric flow connections in accordance with an aspect of the present disclosure. Referring to FIG. 1, the exemplary network system 100 includes a network traffic management apparatus which includes one or more network traffic management systems 222, wherein each system 222 includes one or more network traffic management clusters 220 having one or more network traffic management devices 110 are configured to achieve hardware acceleration for symmetric and asymmetric flow connections.

The exemplary network system 100 can include one or more client devices shown as 104(1)-104(n). Client devices 104(1)-104(n) are coupled to the network traffic management device 110 via network 108, although other communication channels may be implemented. Generally, the client devices 104(1)-104(n) can include virtually any computing device capable of connecting to another computing device to send and receive information, including Web-based information. The set of such devices can include devices that typically connect using a wired (and/or wireless) communications medium, such as personal computers (e.g., desktops, laptops), tablets, set up boxes, mobile and/or smart phones and the like. In this example, the client devices can run browsers and other types of applications (e.g., web-based applications) that can provide an interface to make one or more requests to different server-based applications via the network 108, although requests for other types of network applications may be made by the client devices 104(1)-104(n).

Servers 102(1)-102(n) comprise one or more server computing machines or devices capable of operating one or more Web-based or non Web-based applications that may be accessed by network devices via the network 108, such as client devices 104(1)-104(n)). The server 102 may provide data representing requested resources, such as particular Web page(s), image(s) of physical objects, and any other web objects, in response to requests. It should be noted that the servers 102(1)-102(n) may perform other tasks and provide other types of resources.

The client devices 104(1)-104(n) in an aspect are configured to run interface applications such as Web browsers that can provide a user interface to make requests for and send data to different Web server-based applications via the network 108 and via one or more network traffic management devices 110. A series of network applications can run on the servers 102(1)-102(n) that allow the transmission of data that is requested by the client devices 104(1)-104(n). The servers 102(1)-102(n) can provide data or receive data in response to requests directed toward the respective applications on the servers 102(1)-102(n) from the client devices 104(1)-104(n). For example, as per the Transmission Control Protocol (TCP), packets can be sent to the servers 102(1)-102(n) from the requesting client devices 104(1)-104(n) to send data, although other protocols (e.g., FTP) may be used. It is to be understood that the servers 102(1)-102(n) can be hardware or software or can represent a system with multiple servers, which can include internal or external networks. In this example, the servers 102(1)-102(n) can be any version of Microsoft® IIS servers or Apache® servers, although other types of servers can be used. Further, additional servers can be coupled to the network 108 and/or LAN 106 and many different types of applications can be available on servers coupled to the network 108 and/or LAN 106.

A series of Web-based and/or other types of protected and unprotected network applications can run on the servers 102(1)-102(n) that allow the transmission of data that is requested by the client devices 104(1)-104(n). The client devices 104(1)-104(n) can be further configured to engage in a secure communication with the network traffic management device 110 and/or the servers 102(1)-102(n) using mechanisms such as Secure Sockets Layer (SSL), Internet Protocol Security (IPSec), Tunnel Layer Security (TLS), and the like.

In this example, the network 108 comprises a publicly accessible network, such as the Internet, which includes client devices 104(1)-104(n), although the network 108 may comprise other types of private and public networks that include other devices. Communications, such as requests from client devices 104(1)-104(n) and responses from servers 102(1)-102(n), take place over the network 108 according to standard network protocols, such as the HTTP and TCP/IP protocols in this example, but the principles discussed herein are not limited to this example and can include other protocols (e.g., FTP). Further, the network 108 can include local area networks (LANs), wide area networks (WANs), direct connections, other types and numbers of network types, and any combination thereof. On an interconnected set of LANs or other networks, including those based on different architectures and protocols, routers, switches, hubs, gateways, bridges, crossbars, and other intermediate network devices may act as links within and between LANs and other networks to enable messages and other data to be sent from and to network devices. Also, communication links within and between LANs and other networks typically include twisted wire pair (e.g., Ethernet), coaxial cable, analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, optical fibers, and other communications links known to those skilled in the relevant arts. In essence, the network 108 includes any communication medium and method by which data may travel between client devices 104(1)-104(n), servers 102(1)-102(n), and network traffic management device 110, and these devices are provided by way of example only. By way of example only, network 108 can provide responses and requests according to the Hyper-Text Transfer Protocol (HTTP) based application, request for comments (RFC) document(s) or the Common Internet File System (CIFS) or network file system (NFS) protocol in this example, although the principles discussed herein are not limited to these examples and can include other application protocols and other types of requests (e.g., File Transfer Protocol (FTP) based requests).

By way of example only and not by way of limitation, LAN 106 comprises a private local area network that is connected to the network traffic management device 110 and the one or more servers 102(1)-102(n), although the LAN 106 may comprise other types of private and public networks with other devices. Networks, including local area networks, besides being understood by those of ordinary skill in the relevant art(s), have already been described above in connection with network 108, and thus will not be described further here.

As shown in the example environment of network system 100 depicted in FIG. 1, the network traffic management system 222, which includes one or more network traffic management device clusters 220 can be interposed between the network 108 and the servers 102(1)-102(n) coupled via LAN 106 as shown in FIG. 1. Again, the network system 100 could be arranged in other manners with other numbers and types of devices. It should be understood that the devices and the particular configuration shown in FIG. 1 are provided for exemplary purposes only and thus are not limiting.

Generally, the network traffic management devices 110 in a cluster 220 manage network communications, which may include one or more client requests and server responses, to/from the network 108 between the client devices 104(1)-104(n) and one or more of the servers 102(1)-102(n) in LAN 106 in these examples. These requests may be destined for one or more servers 102(1)-102(n), and may take the form of one or more TCP/IP data packets originating from the network 108 which pass through one or more intermediate network devices and/or intermediate networks until ultimately reaching one or more network traffic management devices 110.

As shown in FIG. 1, the network traffic management system 222 may include one or more network traffic management clusters 220, wherein each network traffic management cluster may include one or more network traffic management devices 110, as shown in FIG. 2B. The clusters 220 are configured to operate in a virtualized mode, whereby individual or combinations of processors or cores 220 among and/or between devices 110 may be used to execute virtual instances.

In an aspect, as discussed in FIG. 2B, one or more network traffic management devices 110 include a plurality of processors 200, whereby the processor(s) 200 allocate one or more connections to the servers 102(1)-102(n), which are one of the many measures of resource utilization of the servers 102(1)-102(n) by the client devices 104(1)-104(n). Some other examples of indicators relating to server resource utilization are bandwidth utilization, processor utilization, memory utilization and the like. In any case, the network traffic management cluster 220 may manage the network communications by performing several network traffic management related functions involving network communications, secured or unsecured, such as load balancing, access control, VPN hosting, network traffic acceleration, encryption, decryption, cookie and key management across multiple devices 110.

FIG. 2A is a block diagram of a network traffic management device in accordance with an aspect of the present disclosure. Referring to FIG. 2A, an example network traffic management device 110 includes one or more device processors or cores 200, one or more device I/O interfaces 202, one or more network interfaces 204, one or more device memories 206 (including an application module 210), one or more distributors or disaggregators 212, and one or more high speed bridges 214, and, all of which are coupled together by bus 208. It should be noted that the device 110 could include other types and numbers of components and is thereby not limited to the configuration shown in FIG. 2A.

FIG. 2B is a block diagram of a network traffic management cluster having a plurality of network traffic management devices in accordance with an aspect of the present disclosure. As shown in the example of FIG. 2B, the cluster 220 includes a plurality of network traffic management devices 110(A)-110(D) which include the processors 200, disaggregators 212, high speed bridge 214 and other components. It should be noted that although four network traffic management devices 110A-110D are shown, any number of network traffic management devices 110 in the system is contemplated. In an aspect, the network traffic management devices 110 may be referred to “blades”, wherein the blades 110 are electronic circuit boards or cards that are installed in a hardware chassis and are configured to communicate with one another over a backplane. In an aspect, virtualized guest services, such as software and other virtualized applications may be executed as virtual instances by one or processors 200 running on different devices 110 in the cluster 220.

Referring back to FIG. 2A, the device processor or core 200 comprises one or more microprocessors configured to execute computer/machine readable and executable instructions stored in device memory 206. Such instructions, when executed by one or more processors, implement network traffic management related functions of the network traffic management device 110. The processor 200 may comprise other types and/or combinations of processors, such as digital signal processors, micro-controllers, application specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”), field programmable logic devices (“FPLDs”), field programmable gate arrays (“FPGAs”), and the like.

Device I/O interfaces 202 comprise one or more user input and output device interface mechanisms. The interface may include a computer keyboard, mouse, display device, and the corresponding physical ports and underlying supporting hardware and software to enable the network traffic management devices 110 to communicate with other devices 110 and/or other network devices in the outside environment. Such communication may include accepting user data input and to provide user output, although other types and numbers of user input and output devices may be used. Additionally or alternatively, as will be described in connection with network interface 204 below, the network traffic management device 110 may communicate with the outside environment for certain types of operations (e.g., configuration) via a network management port. In an aspect, the I/O interface 202 may be a high speed bridge between the bus 208 and the network interface 204. The I/O interface 202 may be a USB bus; an Apple Desktop Bus; an RS-232 serial connection; a SCSI bus; a FireWire bus; a FireWire 800 bus; an Ethernet bus; an AppleTalk bus; a Gigabit Ethernet bus; an Asynchronous Transfer Mode bus; a HIPPI bus; a Super HIPPI bus; a SerialPlus bus; a SCI/LAMP bus; a FibreChannel bus; a Serial Attached small computer system interface bus and the like.

Network interface 204 comprises one or more mechanisms that enable network traffic management device 110 to engage in network communications over the LAN 104 and the network 108 using one or more desired protocols (e.g. TCP/IP, UDP, HTTP, RADIUS, DNS). However, it is contemplated that the network interface 204 may be constructed for use with other communication protocols and types of networks. Network interface 204 is sometimes referred to as a transceiver, transceiving device, or network interface card (NIC), which transmits and receives network data packets to one or more networks, such as LAN 106 and network 108.

In an example where the network traffic management device 110 includes more than one device processor 200, each processor 200 (and/or core) may use the same single network interface 204 or a plurality of network interfaces 204. Further, the network interface 204 may include one or more physical ports, such as Ethernet ports, to couple the network traffic management device 110 with other network devices, such as other network traffic management devices 110 and/or Web servers 102. Moreover, the interface 204 may include certain physical ports dedicated to receiving and/or transmitting certain types of network data, such as device management related data for configuring the network traffic management device 110 and/or client request/server response related data.

Device memory 206 comprises non-transitory computer, processor or machine readable media, namely tangible computer readable or processor readable storage media, which are examples of machine-readable storage media. Computer readable storage/machine-readable storage media may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information. Such storage media includes computer readable/machine-executable instructions, data structures, program modules, or other data, which may be obtained and/or executed by one or more processors, such as device processor 200. Such instructions, when executed by one or more processors, allows control of the general operation of network traffic management device 110 to manage network traffic, implement the application module 210, and perform the process described in the present disclosure. Examples of computer readable storage media include RAM, BIOS, ROM, EEPROM, flash/firmware memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the information.

Bus 208 may comprise one or more internal device component communication buses, links, bridges and supporting components, such as bus controllers and/or arbiters. The bus enables the various components of the network traffic management device 110, such as the processor 200, device I/O interfaces 202, network interface 204, and device memory 206, to communicate with one another. However, it is contemplated that the bus may enable one or more components of the network traffic management device 110 to communicate with components in other devices as well. Example buses include HyperTransport, PCI, PCI Express, InfiniBand, USB, Firewire, Serial ATA (SATA), SCSI, IDE and AGP buses. However, it is contemplated that other types and numbers of buses may be used, whereby the particular types and arrangement of buses will depend on the particular configuration of the network traffic management device 110.

The distributor or disaggregator 212 performs the functions of selectively routing one or more data packets for a virtual instance to one or more selected processors 200 within or among network traffic management devices 110 within the virtualized cluster 220.

High speed bridge or HSB 214 is a hardware device that executes logic to perform various functions with respect to internal execution as well as handling communications with other network traffic management devices 110 in a cluster 220. The HSB 214 may be configured in application specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”), field programmable logic devices (“FPLDs”), field programmable gate arrays (“FPGAs”), and the like. As will be described in more detail below, the HSB 214 in the present disclosure is configured to perform hardware acceleration functions on data packets based on symmetric and/or asymmetric flows.

In an aspect, the network traffic management cluster 220 is configured to provide full virtualization of guest services applications among multiple processors 200 of multiple network traffic management devices 110 within a cluster 220. In particular, when operating in the virtual environment, the network traffic management cluster 220 provides a virtual machine environment in which the individual network traffic management devices 110 provide a virtual simulation of the underlying hardware. With regard to virtualization, one or more network traffic management devices 110 in the network traffic management cluster 220 are configured to perform functions similar to a hypervisor. In particular, the network traffic management devices 110, in acting as a hypervisor, perform one or more hardware virtualization techniques which allow multiple operating systems, applications, or virtual machines (“guest services”), to run concurrently on one or more processors 200 of the devices 110(A)-110(D) in a cluster 220. In other words, the network traffic management devices 110, when operating in the virtualization mode, present a guest service with a virtual operating platform, whereby the network traffic management devices 110 implement and manage the execution of those guest service(s) among an emulated or virtualized set of hardware.

The execution of a guest operation occurs in a virtual instance, whereby one or more processors 200 on one or more network traffic management devices 110(A)-110(D) of the network traffic management system 220 share the virtualized hardware resources to execute a portion or all of the guest service's operations. In particular, the network traffic management devices 110, when operating in a virtualization mode, are able to, per virtual instance, manage the resources of the pre-selected processors 200 for any network traffic management device 110 in the cluster 220.

In general, the present system is directed to a network traffic management system which includes a plurality of network traffic management devices, wherein one or more network traffic management devices contain a plurality of processors or cores 200. The network traffic management devices in the network traffic management system are configured to operate in a full virtualization mode. The system of the present disclosure utilizes a unidirectional-based flow creation and management method, instead of traditional connection based method, to achieve hardware acceleration for both asymmetric and symmetric connection flows. Furthermore, the system and method provides the fundamentals for advanced fine tuned, flow management between the hardware device and the software system to achieve advanced application performance and flexibility.

FIG. 2C illustrates a ladder diagram showing the respective flow segments in a first flow direction and a second flow direction in accordance with an aspect of the present disclosure. As shown in FIG. 2C, a flow connection may contain a first flow direction 250 and a second flow direction 252, whereby the flow connection has a flow signature which contains information to uniquely identify the flow within a connection. The flow signature is usually found in L2, L3 and L4 protocol fields of the data packets in the flow. As shown in FIG. 2C, the network traffic management device 110 receives data packets from the client device 104 in an incoming first flow segment 250A and passes those data packets to the server 102 in an incoming second flow segment 250B. Similarly, the network traffic management device 110 receives data packets from the server 102 in an outgoing first flow segment 252A and passes those data packets to the client device 104 in an outgoing second flow segment 252B.

As will be described in more detail below, when the network traffic management device 110 performs hardware acceleration on the data packets, it will recognize the flow signature of the incoming or outgoing first flow segment 250A or 252A and replace it with the second flow segment 250B, 252B. In the case where the incoming and outgoing flows are symmetric, the segments for each flow direction are reversible. However, if the flows are asymmetric in nature, the flow signatures of the first and second segments in both directions may not be the same or even related to one another.

FIG. 3A illustrates a process performed by the software module of the network traffic management device in accordance with an aspect of the present disclosure. In particular to an aspect in FIG. 3A, the network traffic management system 110 will receive an incoming flow, whereby the software module will perform a connection load balance setup (Block 300). The software module will thereafter determine whether the connection for the received flow is asymmetric or symmetric in nature (Block 302).

Once the type of the flow connection is identified and determined, the software module of the network traffic management device 110 generates a flow signature entry and a transformation information entry for both directions of flow (Block 304). In an aspect, the flow signature may contain VLAN ID information, source IP and destination IP as well as source port, and/or destination port information. It is contemplated that additional and/or different data may be included in the flow signature in an aspect of the present disclosure.

The software module of the network traffic management device 110 then provides the generated flow signature entry and transformation information entry to a hardware acceleration device, such as an ASIC/FPGA hardware device (e.g. high speed bridge or “HSB”) of the network traffic management device 110 (Block 306). The software module then creates a snoop header which contains two flow entries, one for each half of the connection, which is then placed on a DMA transmit ring (Block 308). As will be described in more detail below, the hardware acceleration device, upon receiving this information from the software module, will create corresponding flow signature and transformation entries for its own use whenever hardware acceleration is desired.

When communicating with the high speed bridge, the software engine of the network traffic management device 110 can either embed a header with the flow type, signature and flow transformation information, together with the actual data or pass flow information header via one or more unidirectional based flow creation messages. The protocol header provides sufficient connection and flow information for the correct creation of flow entry in the high speed bridge. The method of embedding the flow header along with actual data can be used for both symmetric and asymmetric flow connection to save extra control network bandwidth. Accordingly, the flow association is decoupled from any single connection session, such that each flow can now be handled properly and uniquely according to the flow nature.

In an aspect, the network traffic management device may apply the process in various load balancing scenarios. For example, the connection may employ a Direct Server Return (DSR), which is an asymmetric-based load balancing option where the server 102, when responding to a client request, sends the response directly to the client device 104, thereby bypassing the network traffic management device 110. In this scenario, the software module of the network traffic management device 110 will send the flow signature entry and the transform information entry to the hardware acceleration device only for flow traveling in the first flow direction (i.e. from client to server).

In another example, the connection may be a HTTP one-connect, whereby the network traffic management device 110 is configured to reuse multiple connections for the second segment (i.e. between the device 110 and the server 102) for multiple client devices 104. In this scenario, the network traffic management device 110 is configured to have the software module handle the second flow segment (i.e. from server to client). At the same time, the software module is configured to provide the flow signature and transform information entries to the hardware acceleration device incoming first flow segment and the outgoing second flow segments. Accordingly, the hardware acceleration device will be configured to handle only the flows between the client device 104 and the network traffic management device 110. Accordingly, this enables the flexibility of dealing with all kinds of hardware flow acceleration based on the nature, type or other factor of the connection irrespective of whether it is symmetric or asymmetric in nature.

FIG. 3B illustrates a method performed by the hardware acceleration device in accordance with an aspect of the present disclosure. The functionality of the high speed bridge is based two processes: flow detection and packet transformation. Packet transform information is stored in a flow table on a per flow basis, wherein each data packet received at the network traffic management device 110 is checked to see if its flow is present in the flow table. If it is, the information from the table is used to transform the packet which is then directly forwarded back to the network. If the packet has a flow which is not in the table, the packet is forwarded to the software module for further processing.

Referring back to FIG. 3B, the HSB, upon receiving data packets from a client device 104, server 102 or other network traffic management device 110, identifies the flow information associated with the received packets (Block 310). The HSB thereafter looks up flow information for the received data packets in a Flow Table (Blocks 312 & 314). Packets without flows in the Flow Table are forwarded to the DMA engines for delivery to the core or processor 200 (Block 316). Packets with flows present in the flow table are transformed and multiplexed into the transmission or Tx Data Path (Block 318).

FIG. 4 illustrates a block diagram of the high speed bridge (HSB) in accordance with an aspect of the present disclosure. As shown in FIG. 4, the flow table used by the HSB can be thought of as a flow cache. As connections are established by software, some are identified as good candidates for hardware transform offload. The flows associated with these connections are pushed or inserted by the software module into the HSB flow cache. Other connections are identified as poor candidates for offload, and their flows are kept by the software module. Flows are deleted from the cache when they become idle or collide with a newer flow. Deleted flows have their flow state information returned to software via a DMA mechanism, as shown in FIG. 4.

The benefit of the HSB shown in FIG. 4 is realized from the fact that each packet that can be fully processed in hardware and returned directly to the network so that valuable CPU resources are not consumed. The benefits of these savings are felt in the conservation of the CPU cycles, I/O bandwidth, memory bandwidth, and CPU cache line turnover. In particular, large packets transiting the CPU sub-system just for header transformation represent a significant load on these elements of the CPU sub-system. When the HSB handles these packets directly, it considerably enhances the systems overall L4 performance.

FIG. 5 illustrates a functional diagram of the HSB operating in conjunction with at least one processor in accordance with an aspect of the present disclosure. FIG. 5 illustrates the elements used to implement functionality of the HSB. In an aspect, the Flow Table is an SRAM based cache of flows available for direct HSB processing. The HSB Lookup module receives packets from the network and looks up their flows in the Flow Table. Packets with flows present in the table are transformed and multiplexed into the transmission or Tx Data Path. Packets without flows in the Flow Table are forwarded to the DMA engines for delivery to the core or processor 200.

As shown in FIG. 5, there are different possible packet flow scenarios for the HSB. In an aspect, where the packet flow is un-cached, as shown by Arrow A, the packet received from the network is looked up and its flow is not found in the flow table. There are many reasons for a flow to not be in the table. This may be a new flow, the software module may have chosen not to cache the flow, or the flow may have been bumped out the table. In any case, the packet is forwarded, unmodified, to the DMA engines for delivery to the core.

For cached flow, shown as Arrow B, the packet received from the network is looked up and a matching entry is found in the flow table. Flow transform information is read from the flow table and applied to the packet. Flow state information is then written back into the table entry. The transformed packet is multiplexed into the TX Data Path for transmission back to the network.

For the scenario where there is flow insertion, as shown by Arrow C, if the software module determines that a connection should be offloaded to the HSB, it creates a snoop header. The snoop header contains two flow entries, one for each half of the connection. Optionally, either of the two flows can be marked as invalid. The snoop header is attached to the front of a frame which is then placed on a DMA transmit ring. Typically, the snoop header and its attached frame are associated with the same connection but this is not required. The software module marks the DMA descriptor to indicate that a snoop header is attached. The DMA hardware detects the snoop header, removes it, and forwards the frame to the TX Data Path. The snoop header is separately passed to the Flow Table for insertion.

For the scenario where there is flow deletion, as shown by Arrow D, the HSB can choose to delete a flow from the Flow Table for several reasons. These include a collision with a newly inserted flow or an old flow being scrubbed from the table. When a flow is deleted, the flow state information is read from the table and forwarded to the DMA engine. The DMA engines uses a management DMA ring to transfer flow state information to the core 200.

Regarding the snoop header described above, FIG. 6A illustrates a HSB single flow snoop header, whereas FIG. 6B illustrates a HSB double flow snoop header, both of which are in accordance with an aspect of the present disclosure. In an aspect, the single flow format in FIG. 6A is 64 bytes and contains the flow specification and transform specification for a single flow, although other byte sizes are contemplated. The double flow format shown in FIG. 6B is 112 bytes and contains the flow specification and transform specification for two flows, although other byte sizes are contemplated. Both of these formats have 16 byte modulus sizes for hardware alignment reasons. The fields in the HSB Snoop Header are defined as follows. All reserved fields have all bits set to zero.

The 3-bit Type field declares the type of the header. The available types are shown in Table 1. Type 2 is used for single flow format headers. Type 3 is used for double flow format headers.

TABLE 1
DMA Buffer Header Types
TYPE Descriptor Format
0    Reserved
1    Standard RT
2    HSB Single Flow
3    HSB Double Flow
4-7  Reserved

The 8-bit Cookie field is loaded by the software. The value is opaque to the hardware and is echoed back to software in the flow teardown message.

In an example aspect, the flow specification fields (for an aspect in which the protocol is IPv4/TCP over Ethernet) can be a 12-bit VLAN ID; a 32-bit IP Source Address; a 32-bit IP Destination Address; a 16-bit TCP Destination Port; and a 16-bit TCP Source Port, although additional, lesser and/or different values and headers may be utilized.

In an example aspect, the flow transformation fields can include a 8-bit TMM number (same as PDE number) which associates the flow with a particular TMM and PDE and can be used as an index to resolve source MAC and HiGig source fields. In an aspect, values from 0-31 are supported in the flow transformation fields, although other values are contemplated. In an example aspect, the flow transformation fields can include a 7-bit HiGig Destination Module ID, a 5-bit HiGig Destination Port number; a 12-bit VLAN ID; a 48-bit Destination MAC Address; a 32-bit IP Source Address; a 32-bit IP Destination Address; a 16-bit TCP Destination Port; a 16-bit TCP Source Port; a 32-bit Sequence Number Delta adjustment value; a 32-bit Acknowledgement Number Delta adjustment value; and/or a 32-bit Timestamp Delta adjustment value.

FIG. 7 illustrates an exemplary HSB Flow Cache table entry in accordance with an aspect of the present disclosure. The cache entry is laid out into sixteen 36-bits wide words. Each word is protected by parity and bit 35 is assigned as the parity (P) bit. The overall entry is divided into three functional sections; a 4-word flow specification, an 8-word transform specification, and a 4-word flow state. The size of these regions is based on the burst-of-4 access style of the underlying SRAM technology and must be respected. The flow specification is used to fully identify the flow and any packets belonging to it. The flow transformation is used to modify these packets for transmission back to the network without involvement of the software module. The flow state is used to track events in the flow that need to be communicated back to software module when the flow is torn down.

In an aspect, the flow cache entry fields, such as the flow specification, can include a 8-bit Cookie value which is opaque to the hardware and is echoed back to software in the flow teardown message. The flow specification, in an aspect, can include a 12-bit VLAN ID; a 32-bit IP Source Address; a 32-bit IP Destination Address; a 16-bit TCP Destination Port; and/or a 16-bit TCP Source Port.

Regarding the flow transformation field in the flow cache entry, the flow transformation field, in an aspect, can include: a 7-bit HiGig Destination Module ID; a 12-bit VLAN ID; a 48-bit Destination MAC Address; a 5-bit TMM number (e.g. PDE number used as an index to resolve source MAC and HiGig source fields, in which the TMM number is split across two SRAM words); a 32-bit IP Source Address; a 5-bit HiGig Destination Port number which can be split across two SRAM words; a 32-bit IP Destination Address; a 16-bit TCP Destination Port; a 16-bit TCP Source Port; a 32-bit Sequence Number Delta adjustment value; a 32-bit Acknowledgement Number Delta adjustment value; and/or a 32-bit Timestamp Delta adjustment value.

Regarding the flow state field in the flow cache entry, the flow state field, in an aspect, can include a 4-bit Scrub Count. The Scrub Count value reflects the age of the flow. The count is set/reset to its start value when the flow is inserted into the cache and each time a packet is processed for the flow. The count is decremented each time the scrubber accesses the flow. When this counter reaches zero the flow is torn down and removed from the cache. The counter is loaded to a value of 1 when a FIN packet is processed to accelerate aging of the flow.

In an aspect, the flow state field can include a 24-bit Packet Counter. In an example, the 24-bit Packet Counter is initialized to zero when the flow is inserted into the cache. The counter is incremented by one each time a packet is processed for the flow, wherein the final counter value is sent to the software when the flow is torn down.

In an aspect, the flow state field can include a 32-bit Byte Counter. For example, such a counter can be initialized to zero when the flow is inserted into the cache. The counter then increments by the packets byte length each time a packet is processed for the flow. The final counter value is sent to the software when the flow is torn down.

In an aspect, the flow state field can include a Last Sequence Number which records the last sequence number seen by the flow. The Last Sequence Number is initialized to zero when the flow is inserted, wherein the Number is updated with each packet processed for the flow until a FIN is seen. After the FIN is seen, the Last Sequence Number is no longer updated.

In an aspect, the flow state field can include a Last Acknowledgement Number. This Last Acknowledgement Number is initialized to zero when the flow is inserted, wherein the field records the last acknowledgment number seen by the flow. The number is updated with each packet processed for the flow with an ACK bit set.

The flow state field, in an aspect, can include: 4-bit Flow State Flags which record state events seen on the flow. The Flow State Flags are updated with each packet processed by the flow.

For instance in an aspect, FLAG[0] is reserved and is set to a value of zero.

FLAG[1] represents SEQ # Valid, whereby this bit is cleared when the flow is inserted into the cache or the bit is set if at least one packet has been processed by the flow and the Last SEQ Number field has a valid value.

In another aspect, FLAG[2] represents that ACK # Valid, wherein the bit is cleared when the flow is inserted into the cache or the bit is set if at least one ACK packet has been processed by the flow and the Last ACK Number field has a valid value.

In another aspect, FLAG[3] represents FIN Seen, whereby the bit is cleared when the flow is inserted into the cache or the bit is set when a FIN packet has been processed by the flow. When this bit is set, the scrub count is also set to 1 to accelerate aging of the flow.

FIG. 8 illustrates an exemplary HSB Teardown descriptor in accordance with an aspect of the present disclosure. The descriptor is 32 bytes in size and consumes two slots in the descriptor ring, although other byte sizes are contemplated.

Having thus described the basic concepts, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. The order that the measures and processes for providing secure application delivery are implemented can also be altered. Furthermore, multiple networks in addition to network 108 and LAN 106 could be associated with network traffic management device 110 from/to which network packets can be received/transmitted, respectively. These alterations, improvements, and modifications are intended to be suggested by this disclosure, and are within the spirit and scope of the examples. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes and methods to any order except as can be specified in the claims.

Claims

1. A method for data packet processing implemented by a network traffic management system operating in a network environment comprising one or more network traffic management devices, one or more server devices, or one or more client devices, wherein at least one of the network traffic management devices includes a software component implemented by a general processing unit and a hardware component configured for packet processing, the method comprising: receiving at the at least one network traffic management device one or more data packets associated with a sub-flow within a connection containing at least two sub-flows wherein each sub-flow is associated with a direction within the connection;determining, by the at the at least one network traffic management device, when a flow entry exists in a flow cache table of the hardware component for a sub-flow associated with the one or more data packets;when the determining indicates that the flow entry does not exist in the flow cache table, the software component performs the following actions: generate a snoop header for the one or more data packets that comprises flow signature information comprising a flow signature entry and transformation information comprising a transformation data entry for each of a first flow direction of the sub-flow of the connection and a second flow direction opposite the first flow direction of the sub-flow of the connection, andprovide the snoop header comprising the flow signature information and the transformation information to the hardware component for incorporation into the flow cache table for further processing of the one or more data packets associated with the sub-flow; andwhen the determining indicates that the flow entry does exist in the flow cache table, the hardware component performs the following actions: obtain the flow signature information and the transformation information from the flow cache table,transform the one or more data packets using at least one of the flow signature information and the transformation information, andtransmit the one or more transformed data packets through the sub-flow of the connection associated with the one or more data packets.

2. The method of claim 1, wherein the hardware component is configured to be capable of extracting and using the flow signature entry and the transformation data entry from the snoop header to generate entries in the flow cache table for each of the first and second flow directions.

3. The method of claim 1, wherein the first flow direction comprises a first connection between one of the client devices and the at least one network traffic management device, and the second flow direction comprises a second connection between the at least one network traffic management device and one of the server devices or a third connection between one of the server devices and one of the clients devices.

4. The method of claim 1, wherein at least one of the first or second flow directions is asymmetrical.

5. The method of claim 1, further comprising selecting by the at least one of the network traffic management devices some of the one or more data packets for processing by the hardware component and selecting at least some other data packets for processing by the software component.

6. The method of claim 5, further comprising processing, by the software component, the at least some other data packets selected for processing by the software component rather than the hardware component for transmission through the sub-flow of the connection associated with the at least some other data packets without providing any flow signature and transformation information for the associated sub-flow to the hardware component.

7. The method of claim 1, further comprising removing, by the hardware component, the flow signature information and the transformation information for a particular sub-flow from the flow cache table when either there is a collision with the flow signature information and the transformation information of another sub-flow or the flow signature and transformation information has aged out.

8. A network traffic management device, comprising a hardware component configured for processing packets, one or more processors, and a software component, wherein: the hardware component comprises configurable hardware logic configured to: receive one or more data packets associated with a sub-flow within a connection containing at least two sub-flows wherein each sub-flow is associated with a direction within the connection;determine when a flow entry exists in a flow cache table of the hardware component for a sub-flow associated with the one or more data packets; andthe software component comprises memory comprising programmed instructions stored thereon and the one or more processors are configured to be capable of executing the stored programmed instructions to, when the determining indicates that the flow entry does not exist in the flow cache table: generate a snoop header for the one or more data packets that comprises flow signature information comprising a flow signature entry and transformation information comprising a transformation data entry for each of a first flow direction of the sub-flow of the connection and a second flow direction opposite the first flow direction of the sub-flow of the connection, andprovide the snoop header comprising the flow signature information and the transformation information to the hardware component for incorporation into the flow cache table for further processing of the one or more data packets associated with the sub-flow; andthe configurable hardware logic component is further configured to, when the determining indicates that the flow entry does exist in the flow cache table: obtain the flow signature information and the transformation information from the flow cache table,transform the one or more data packets using at least one of the flow signature information and the transformation information, andtransmit the one or more transformed data packets through the sub-flow of the connection associated with the one or more data packets.

9. The network traffic management device of claim 8, wherein the hardware component is configured to be capable of extracting and using the flow signature entry and the transformation data entry from the snoop header to generate entries in the flow cache table for each of the first and second flow directions.

10. The network traffic management device of claim 8, wherein the first flow direction comprises a first connection between a client device and the network traffic management device, and the second flow direction comprises a second connection between the network traffic management device and a server device or a third connection between the server device and the clients device.

11. The network traffic management device of claim 8, wherein at least one of the first or second flow directions is asymmetrical.

12. The network traffic management device of claim 8, wherein the one or more processors are configured to be capable of executing the stored programmed instructions to select some of the one or more data packets for processing by the hardware component and select at least some other data packets for processing by the software component.

13. The network traffic management device of claim 12, wherein the one or more processors are configured to be capable of executing the stored programmed instructions to process the at least some other data packets selected for processing by the software component rather than the hardware component for transmission through the sub-flow of the connection associated with the at least some other data packets without providing any flow signature and transformation information for the associated sub-flow to the hardware component.

14. The network traffic management device of claim 8, wherein the configurable hardware logic of the hardware component is further configured to remove the flow signature information and the transformation information for a particular sub-flow from the flow cache table when either there is a collision with the flow signature information and the transformation information of another sub-flow or the flow signature and transformation information has aged out.

15. A non-transitory computer readable medium having stored thereon instructions for processing network packets comprising executable code which when executed by one or more processors, causes the one or more processors to, when a hardware component determines that a flow entry does not exist in a flow cache table: generate a snoop header for the one or more data packets that comprises flow signature information comprising a flow signature entry and transformation information comprising a transformation data entry for each of a first flow direction of the sub-flow of the connection and a second flow direction opposite the first flow direction of the sub-flow of the connection, andprovide the snoop header comprising the flow signature information and the transformation information to the hardware component for incorporation into the flow cache table for further processing of the one or more data packets associated with the sub-flow, wherein the hardware component comprises configurable hardware logic configured to, when the hardware component determines that the flow entry does exist in the flow cache table: obtain the flow signature information and the transformation information from the flow cache table,transform the one or more data packets using at least one of the flow signature information and the transformation information, andtransmit the one or more transformed data packets through the sub-flow of the connection associated with the one or more data packets.

16. The non-transitory computer readable medium of claim 15, wherein the hardware component is configured to be capable of extracting and using the flow signature entry and the transformation data entry from the snoop header to generate entries in the flow cache table for each of the first and second flow directions.

17. The non-transitory computer readable medium of claim 15, wherein the first flow direction comprises a first connection between a client device and a network traffic management device, and the second flow direction comprises a second connection between the network traffic management device and a server device or a third connection between the server device and the clients device.

18. The non-transitory computer readable medium of claim 15, wherein at least one of the first or second flow directions is asymmetrical.

19. The non-transitory computer readable medium of claim 15, wherein the executable code when executed by the one or more processors further causes the one or more processors to select some of the one or more data packets for processing by the hardware component and select at least some other data packets for processing by the software component.

20. The non-transitory computer readable medium of claim 19, wherein the executable code when executed by the one or more processors further causes the one or more processors to process the at least some other data packets selected for processing by the software component rather than the hardware component for transmission through the sub-flow of the connection associated with the at least some other data packets without providing any flow signature and transformation information for the associated sub-flow to the hardware component.

21. The non-transitory computer readable medium of claim 19, wherein the configurable hardware logic of the hardware component is further configured to remove the flow signature information and the transformation information for a particular sub-flow from the flow cache table when either there is a collision with the flow signature information and the transformation information of another sub-flow or the flow signature and transformation information has aged out.