WO2013063791A1 - Accélérateur nat/pare-feu - Google Patents

Accélérateur nat/pare-feu Download PDF

Info

Publication number
WO2013063791A1
WO2013063791A1 PCT/CN2011/081785 CN2011081785W WO2013063791A1 WO 2013063791 A1 WO2013063791 A1 WO 2013063791A1 CN 2011081785 W CN2011081785 W CN 2011081785W WO 2013063791 A1 WO2013063791 A1 WO 2013063791A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
nat
packets
interface
fastnat
Prior art date
Application number
PCT/CN2011/081785
Other languages
English (en)
Inventor
Tos XU
Xiaoping FAN
Original Assignee
Qualcomm Atheros, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Atheros, Inc. filed Critical Qualcomm Atheros, Inc.
Priority to PCT/CN2011/081785 priority Critical patent/WO2013063791A1/fr
Publication of WO2013063791A1 publication Critical patent/WO2013063791A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/255—Maintenance or indexing of mapping tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • This invention relates generally to computer networking, and more particularly to the design of a Network Address Translation (NAT)/Firewall accelerator.
  • NAT Network Address Translation
  • Firewalls are devices designed to regulate network transmissions between networked devices based upon a set of rules, and are frequently used to protect networks from unauthorized access while permitting legitimate communications and data exchange.
  • Many operating systems on personal computers (PCs) include firewalls, typically software-based, to protect against threats from outside network sources (e.g. from a wide area network).
  • Many network routers also contain firewall components, and conversely, some firewalls can also perform basic routing functions.
  • a primary function of firewalls is packet filtering, during which data packets transmitted between computers on the network are inspected. If a packet matches a set of rules specified in a packet filter, the packet filter will drop the packet, or discard the packet, and send an error message to the packet source.
  • Packet filtering firewalls work mainly on the first three layers of the OSI (Open Systems Interconnection) reference model, performing the bulk of the work between the network and physical layers, with some activity at the transport layer level to determine source and destination port numbers.
  • OSI Open Systems Interconnection
  • firewalls There are different types of firewalls depending on where the communication is taking place, where the communication is intercepted, and the state that is being traced.
  • Network layer firewalls also called packet filters, operate at a relatively low level of the TCP/IP protocol stack, preventing packets from passing through the firewall unless the content of the packets match an established set of rules.
  • Most current firewalls can filter traffic based on many packet attributes like source IP address, source port, destination IP address or port, destination service like WWW or FTP, and can also filter based on protocols and many other attributes.
  • Application-layer firewalls work on the application level of the TCP/IP stack, and may intercept all packets transferred to or from an application. Other packets are blocked, most often dropped without acknowledgment to the sender. In principle, application firewalls can prevent all unwanted outside traffic from reaching protected machines.
  • Firewalls often have network address translation (NAT) functionality. Accordingly, hosts protected behind a firewall commonly have addresses in a private address range, as defined in RFC 1918. Firewalls often have such functionality to hide the true address of protected hosts.
  • the NAT functionality was originally developed to address the limited number of IPv4 routable addresses that could be used or assigned to companies or individuals, in addition to reducing both the amount, and therefore cost, of obtaining enough public addresses for every computer in an organization.
  • NAT is the process of modifying IP address information in IP packet headers while in transit across a traffic routing device.
  • NAT The simplest type of NAT provides a one to one translation of IP addresses.
  • IP addresses In this type of NAT only the IP addresses, IP header checksum, and higher-level checksums that include the IP address need to be changed. The rest of the packet is typically left untouched with respect to basic TCP/UDP functionality, while some higher-level protocols may require further translation.
  • Basic NATs can be used, for example, when there is a requirement to interconnect two IP networks with incompatible addressing. It is however not uncommon to hide an entire IP address space, usually consisting of private IP addresses, behind a single IP address, or in some cases a small group of IP addresses, in another, usually public address space.
  • a one-to-many NAT is typically required to modify higher-level information, such as TCP/UDP ports in outgoing communications, and maintain a translation table to ensure that return packets are correctly translated.
  • NAT became popular for alleviating the consequences of IPv4 address exhaustion. It has become a common feature in routers for home and small- office Internet connectivity, enabling multiple hosts on a private network to access the Internet using a single public IP address.
  • network address translation can have serious drawbacks on the quality of Internet connectivity, and generally requires careful attention to detail in its implementation.
  • NAT can be said to break the originally envisioned model of IP end-to-end connectivity across the Internet, and it is difficult for systems behind a NAT to accept incoming communications.
  • some NAT traversal methods have been devised to alleviate these issues.
  • existing firewall/NAT solutions based on Linux, for example, cater to the needs of target customers, they consume lot of CPU time/cycles during operation. Such heavy consumption of CPU time hampers the performance of wireless/wired traffic apart from other optional applications.
  • NAT/Firewall operations may be offloaded from the OS (Operating System - e.g. Linux) kernel to a dedicated engine, which may be implemented as a dedicated software driver or a hardware component or a combination of both, to perform firewall and basic NAT operations.
  • OS Operating System - e.g. Linux
  • a dedicated engine which may be implemented as a dedicated software driver or a hardware component or a combination of both, to perform firewall and basic NAT operations.
  • a dedicated software accelerator, a dedicated hardware accelerator, or a combination of the two may provide a mechanism where NAT, routing, and Firewall functionality is offloaded to the dedicated hardware, the dedicated software driver, or to the combination of the two, thereby bypassing the OS kernel netfilter process and freeing up CPU time to perform other tasks.
  • a first packet in a new incoming (or outgoing) packet stream may proceed through an OS kernel netfilter process, during which a dedicated offload engine may generate a NAT table entry for the packet.
  • Subsequent packets in the same packet stream i.e. originating as part of the same connection, may also be processed by the dedicated offload engine and may be checked against entries in the NAT table. If a packet registers a hit in the NAT table, the packet undergoes a series of operations performed by the dedicated offload engine, thereby allowing the packet to bypass the OS kernel netfilter process.
  • the series of operations may include an ACL (Access Control List) check to determine if the packet is to be dropped, a mangle operation to modify DSCP (Differentiated Services Code Point), SKB (Socket Buffer) priority, and mark, a NAT operation to modify layer3 IP and layer 4 port, and a routing operation to select an appropriate layer3 output interface.
  • ACL Access Control List
  • DSCP Differentiated Services Code Point
  • SKB Socket Buffer
  • the series of operations may all be performed in software as part of a dedicated software driver that moves packets between layer3 interface drivers (i.e. between layer3 interface driver Receive - Rx, and layer3 interface driver Transmit - Tx) operating in the OS.
  • layer3 interface drivers i.e. between layer3 interface driver Receive - Rx, and layer3 interface driver Transmit - Tx
  • some of the more CPU intensive operations e.g. checksum calculation, hash NAT table lookup, and/or packet modification may be implemented in a dedicated hardware block/circuit.
  • an offload hardware module may be connected between the CPU and one or more Gigabit MAC (Gigabit Media Access Control - GMAC) interfaces.
  • Gigabit MAC Gigabit Media Access Control - GMAC
  • the offload hardware module may perform ACL check, mangle (Quality of Service) operations, and PPPoE (Point-to-Point Protocol over Ethernet) operations.
  • the offload hardware module may have a virtual Ethernet interface in the OS, e.g. in the Linux OS in a Linux system, and may receive and transmit Ethernet packets. It may insert two additional bytes in the packet header of each packet: an operation code byte and an interface index byte, to indicate direction of the packet and the source/destination of the packet.
  • the offload hardware module may directly transfer packets between the GMAC interfaces, and may initiate DMA (Direct Memory Access) transfers to transfer packets between a GMAC interface and a layer3 virtual interface in the OS, and between layer3 virtual interfaces in the OS. During DMA transfers, for each respective transfer, the packets may move through the offload hardware module and system memory between the respective source interface and the respective target interface for the respective transfer.
  • DMA Direct Memory Access
  • FIG. 1 shows a partial block diagram of one embodiment of a NAT/Firewall architecture, in which NAT/Firewall functionality is established within the OS (operating system) kernel;
  • Fig. 2 shows one example of a netfilter framework
  • FIG. 3 shows a flow diagram illustrating netfilter packet flow according to one embodiment
  • FIG. 4 shows a diagram illustrating the operation of one embodiment of a hardware accelerator (HNAT) that offloads NAT functionality from the OS kernel;
  • HNAT hardware accelerator
  • Fig. 5 shows a diagram illustrating the operation of one embodiment of an accelerator (FastNAT) that offloads NAT and other packet processing functionality from the OS kernel;
  • FastNAT accelerator
  • Fig. 6 shows a diagram illustrating the operation of one embodiment of a mixed (hardware and software) accelerator that offloads NAT and other packet processing functionality from the OS kernel;
  • FIG. 7 shows one embodiment of a possible firewall table
  • Fig. 8 shows a table with entries providing command data interpretation for an HNAT, according to one embodiment
  • FIG. 9 shows embodiments of HNAT tables
  • Fig. 10 shows a diagram illustrating ingress (incoming) packet flow for an HNAT, according to one embodiment
  • Fig. 11 shows a table describing the packet structure with respect to ingress packet flow for an HNAT, according to one embodiment
  • Fig. 12 a diagram illustrating egress (outgoing) packet flow for an HNAT, according to one embodiment
  • Fig. 13 shows a table describing the packet structure with respect to egress packet flow for an HNAT, according to one embodiment
  • Fig. 14 shows a table with entries used by a FastNAT, according to one embodiment
  • FIG 15 shows the packet flow for a FastNAT, according to one embodiment
  • Fig 16 shows the packet flow for a mixed accelerator (hardware FastNAT) according to one embodiment
  • Fig 17 shows the block diagram for one embodiment of a system that includes a FastNAT module implemented in hardware.
  • Embodiments of the invention may operate in a computer system, which includes a network interface device that couples to a network, e.g., a wide area network such as the Internet.
  • the computer system may comprise a CPU and memory.
  • the memory may store an operating system (OS) having a kernel as well as OS components.
  • OS operating system
  • the network interface device in the computer receives packets over the wide area network, and the packets are processed by software executing in the computer system.
  • the received packets may be organized according to a first communication protocol (e.g., ipv4), and may be processed using a software communication stack according to the communication protocol.
  • a first communication protocol e.g., ipv4
  • the computer system may also comprise a dedicated hardware engine and/or a dedicated software program to perform NAT (Network Address Translation) and/or other operations (e.g. firewall operations) as further described in detail below.
  • NAT Network Address Translation
  • Embodiments of the invention may also operate in various other devices, such as network devices, e.g., switches, hubs, gateways, bridges, routers, etc.
  • one or more (or all) NAT (Network Address Translation)/Firewall operations may be offloaded from the OS (Operating System - e.g. a Linux OS) kernel to a dedicated hardware engine, a dedicated software program (e.g., a driver), or a combination of hardware and software.
  • OS Operating System
  • a dedicated software program e.g., a driver
  • CPU bandwidth may be preserved for executing operations associated with other, applicable modules.
  • NAT and other packet processing functionality may be offloaded to a dedicated hardware module, a dedicated software driver, or a combination of the two, to allow eligible packets to bypass the OS kernel's netfilter process, thereby freeing up CPU resources.
  • Fig. 1 shows a partial block diagram of one embodiment of an operating system architecture showing NAT/Firewall functionality established within the OS kernel, which in the example shown is a Linux kernel.
  • the NAT/Firewall functionality is implemented within the OS kernel 150.
  • the NAT/Firewall functionality may interface with a Connection Tracking module 104, which may interface with a Netfilter 106 interfacing with the OS's IP layer 108.
  • Fig. 1 specifically illustrates NAT functionality 102a, firewall functionality 102b, and mangle (Quality of Service - QoS) functionality 102c. More detailed functionality of these modules is further discussed in below.
  • the Netfilter framework may essentially couple into certain places in the network stack code through which packets flow.
  • the netfilter framework may be a part of the OS kernel functionality.
  • the netfilter framework allows the higher layers (NAT, Firewall etc.,) to manipulate the contents or disposition of the traffic at certain points within the kernel structure.
  • Those points in the kernel include:
  • ⁇ Forward forward the packet, which is not intended for a local destination
  • ⁇ Local out send out the packet, which is from a local source
  • ⁇ Postrouting transmit the packet, after a routing decision has been made.
  • the netfilter framework is represented by block 106 in Fig. 1, and a more detailed view of netfilter 106 is shown in Fig. 2, with the information flow illustrated with respect to the above listed points in the OS kernel.
  • a received packet may arrive to Prerouting point 204, where certain operations may be performed on the packet. Those operations may include connection tracking, mangle, and destination NAT.
  • a determination may be made whether the packet is intended for a local destination point or it is to be forwarded.
  • mangle and filtering may be performed at the "Local in” point 208, and again at the "Local out” point 210, before the packet arrives to the Postrouting point 214, where mangle, source NAT, and connection tracking confirmation may be performed on the packet. If the packet is to be forwarded, as determined at routing point 206, mangle and filtering may be performed at Forward point 212, from where the packet may be sent directly to Postrouting point 214.
  • Connection tracking module 104 may maintain the TCP/UDP/ICMP connection information in the form of tables that include source, destination IP address, port number pairs (known as socket pairs), protocol type, connection state and timeout information for the packet.
  • NAT module 102a and Firewall module 102b may make heavy use of Connection Tracking module 104 for their functionality.
  • Firewall module 102b may filter the packets based on rules that incorporate information on ipv4 (Internet Protocol version 4) address, options, TCP (Transmission Control Protocol) port, etc. Firewall module 102b may take the action specified by the rule. That is, Firewall module 102b may take action according to the rules descriptions. In addition to the above listed options, a list of packet states (New, Established, etc.,) may also be specified as part of the rules, thus providing another level of security.
  • ipv4 Internet Protocol version 4
  • NAT module 102a may provide the facility to translate protocol level addresses, ports, etc., along with the additional modification of Layer5-Layer7 layer data using ALG (Application layer gateway) modules (for ftp, sip, h.323, http etc.)
  • ALG Application layer gateway
  • Mangle (Quality of Service - QoS) module 102c may provide the facility to manipulate the ipv4 TOS (Type of Service)/DSCP (Differentiated Services Code Point) field, and mark the packet for special processing. Accordingly, Mangle module 102c may be used for providing software QoS.
  • a netfilter packet flow 300 is shown in the flow diagram of Fig. 3.
  • the packet flow is illustrated from a network card (NC) 302 to a local process 326, and back to the NIC 302. That is, packet flow 300 illustrates the packet flow between a NC 302 and a local process 326.
  • NC network card
  • packet flow 300 illustrates the packet flow between a NC 302 and a local process 326.
  • the raw packet 306 undergoes connection tracking 308, mangle 310, and destination NAT 312.
  • the resulting packet then undergoes routing 316 following ingress QoS 314.
  • the packet If the packet is intended for a local destination, it goes to input point 318, where the packet undergoes a mangle operation 320 and filtering 322, from which all non-tunneled packets are delivered to the intended local process 326. Tunneled packets are returned to prerouting 304. If the packet is intended for a non-local destination, it goes to the forward point 328, where the packet undergoes a mangle operation 330 and filtering 332, subsequently reaching postrouting 346, where it undergoes a mangle operation 348 and source NAT 350, following which the packet undergoes egress QoS 352 before being sent out through network card 302.
  • Packets received from local process 326 go to output point 334, where the raw packet 335 undergoes connection tracking 336, mangle operation 338, destination NAT 340, and filtering 342, before undergoing routing 344 to postrouting point 346. It should be noted here, that packets may actually be routed prior to reaching the output point 334, but they may be rerouted at routing point 344 if the destination of the packet changes. It should also be noted - regarding destination NAT 312, destination NAT 340, and source NAT 350 - that for ipv6 packets tunneled over ipv4, the NAT table may be traversed once the first packet of the tunnel has gone through.
  • various accelerators may be implemented to offload NAT and other packet processing functionality (e.g. Firewall functionality) from OS kernel 150. These accelerators may be implemented in hardware or software or a combination of both. In one set of embodiments, only NAT functionality may be performed by a hardware accelerator (referenced hereinafter as HNAT). In another set of embodiments, NAT functionality may be performed in a software driver operating outside the OS kernel. In yet another set of embodiments, a more diverse dedicated accelerator (referenced hereinafter as FastNAT) may perform NAT and other packet processing functionality in software (operating outside the OS kernel), hardware, or a combination of both.
  • HNAT hardware accelerator
  • FastNAT a more diverse dedicated accelerator
  • a system may include only an HNAT, or the system may integrate a FastNAT for which one or more or all functionality is implemented in hardware.
  • the hardware-implemented functions may be designed or specified to operate within a designated hardware platform.
  • the hardware and software functionality for a mixed accelerator also referred to as hardware FastNAT may be designed to seamlessly cooperate with each other.
  • An HNAT module may be a specific/designated module/block within the designated hardware platform to perform network address translation.
  • the packets may still go through the OS (e.g. Linux) netfilter process (e.g. netfilter module/process 106 shown in Fig. 1), but they are not processed by NAT module 102a within the OS kernel, since NAT is performed by the HNAT module.
  • the HNAT may be designed to support designated packet types, for example ipv4 packets.
  • the packets may also not need to go through the OS netfilter process, as will be further described below.
  • a FastNAT module may be implemented as a software accelerator, or a hardware accelerator, or a combination of both.
  • certain CPU-intensive operations performed by the FastNAT module e.g. NAT, checksum calculation, hash NAT table lookup, and/or packet modification
  • the FastNAT module may be implemented as a hardware switch/module (as will be further described below with respect to Fig. 17.)
  • FastNAT may run on all hardware platforms, and it may be written to support all packet types.
  • any first packet in a new packet stream may go through the OS kernel netfilter process, during which FastNAT may create a FastNAT table entry. Subsequent packets in the same packet stream processed by FastNAT are checked against entries in the FastNAT table, and if a packet hits one of the entries, that packet may bypass the OS kernel netfilter process.
  • network address translation by FastNAT may be performed in software, or it may be performed in hardware (e.g. by HNAT cooperating with FastNAT).
  • packets subsequent to an initial packet in any packet stream may bypass the OS kernel netfilter process, and may also bypass routing in the OS kernel (e.g. routing 316 shown in Fig. 3).
  • HNAT module may be performed in software, or it may be performed in hardware (e.g. by HNAT cooperating with FastNAT). In any case, packets subsequent to an initial packet in any packet stream may bypass the OS kernel netfilter process, and may also bypass routing in the OS kernel (e.g. routing 316 shown in Fig. 3).
  • the operation of one embodiment of a hardware accelerator that performs (only) NAT is shown in the diagram 400 of Fig. 4.
  • the hardware accelerator may run on a designated hardware platform, using a dedicated hardware module 402, and may be designed to support specific packet types, for example ipv4 simple connection packets.
  • Unsupported packets which in this case may include non-ipv4 packets, fragmented ipv4 packets, and/or ipv4 complex connection ALG (Application Layer Gateway) packets may go through the OS netfilter process as per normal operation. If a packet has undergone destination network address translation (DST NAT) in hardware, it may bypass DST NAT in software at the prerouting point (referring back to Fig.
  • DST NAT destination network address translation
  • the packet may bypass destination NAT 312 at prerouting point 304). If a NAT entry has been added into a hardware egress table, the packet may be marked with hardware source network address translation (SRC NAT) at the prerouting point, and may thus bypass SRC NAT at postrouting (referring back to Fig. 3, the packet may bypass source NAT 350 at postrouting point 346).
  • SRC NAT hardware source network address translation
  • a dedicated HNAT module 402 may perform NAT on supported packet types.
  • a received packet may be processed by HNAT module 402, according to an ACL (Access Control List) ingress table 404 and NAT ingress table 406, based on which module 402 may perform the network address translation, sending the packet to the netfilter process 106 where the packet is then handled by the software driver (receive - Rx 414).
  • unsupported packets may directly go to netfilter process 106, where the packets are handled by the software driver 414.
  • the driver may mark the socket buffer (SKB) with NAT/ACL information according to the received descriptor. Accordingly, at prerouting point 416, connection tracking may be performed on all received packets.
  • a NAT entry may be added to egress table 408 for supported connections if software SRC NAT has been performed, or a connection has been established.
  • a NAT entry may be added to ingress table 406 for supported connections, if software DST NAT has been performed, or a connection has been established. If the packet is from the LAN (Local Area Network) and its connection has been added into hardware, the packet may be marked with a hardware SRC NAT flag. Mangle may be performed on all packets. Finally, a DST NAT is performed only on packets for which DST NAT has not yet been performed by module 402.
  • the packet may undergo routing 418, which may result in the packet being routed to local in 422 and eventually to local out 424 for local destination, or forwarded to forward point 420.
  • routing 418 may result in the packet being routed to local in 422 and eventually to local out 424 for local destination, or forwarded to forward point 420.
  • forward point 420 mangle is performed for all packets, while filtering is performed on packets without hardware ACL.
  • outgoing packets go through postrouting point 426, where mangle may be performed on all packets.
  • An SRC NAT is performed on packets that do not have a hardware SRC NAT flag. Connection tracking is also confirmed for all packets.
  • the outgoing packets are handled by the driver (Transmit - Tx 428), which may mark the sent descriptor with the NAT/ACL info according to the sent SKB.
  • FastNAT may be implemented as a software driver (operating outside the OS kernel), a hardware module, or a combination of both.
  • FastNAT may perform not only NAT but other packet processing functions as well, resulting in the packets not having to be handled in the communication stack software running in the OS kernel.
  • FastNAT may be written as a pure software driver for all functions except NAT, which may be performed by HNAT, which may cooperate with the FastNAT software module.
  • FastNAT may operate to transmit packets to/from the layer3 interface, and modify the packet according to the rules set for NAT and Mangle.
  • a first packet in a new packet stream may go through the OS kernel netfilter process, during which FastNAT creates a FastNAT table entry corresponding to the connection. Subsequent packets that hit an entry in the FastNAT table do not have to traverse the OS network stack, which saves CPU time. If the packet doesn't hit a FastNAT entry, it may traverse (go through) the OS network stack as per normal operation (see Fig. 1, for example). All software components of the FastNAT module may be written to run on any one or more hardware platforms, and may be written to support any or all packets/packet types. [0048] As seen in Fig. 5, a FastNAT module 506 may process packets incoming from the layer 3 interface receive driver 504.
  • FastNAT module 506 may be implemented as software code executed to process the incoming packets. As part of the operation of FastNAT module 506, the FastNAT table (mentioned above) set up by FastNAT module 506 upon processing the first packet of a new packet stream may be searched to see if there is a match for the packet (i.e. to determine if the packet hits). If the packet hits, FastNAT module 506 may perform the following operations:
  • ⁇ a mangle operation to modify DSCP, SKB priority, and mark.
  • FastNAT module 506 may provide the packet to the layer3 interface transmit driver 520.
  • the packet may be provided to the OS network stack, where it may go through the prerouting point 508, where connection tracking, mangle, and DST NAT may be performed. From there, the packet may go through routing 510. For local destination, the packet is routed to local in 514, where mangle and filtering may be performed, the packet moving to the local out point 516, where mangle and filtering may again be performed before providing the packet to postrouting point 518. For non-local destinations, the packet goes through forward point 412 where mangle and filtering may be performed before providing the packet to postrouting point 518.
  • a FastNAT entry may be added for supported connections, when a connection is established. Furthermore, respective DST NAT and SRC NAT entries may also be added for the connection, one in the original direction of the packet, and one in the reply direction of the packet.
  • the FastNAT entry may also include ACL, route, and mangle decision information.
  • FIG. 6 The operation of one embodiment of a mixed HNAT/FastNAT accelerator is illustrated in the diagram 600 of Fig. 6.
  • the NAT function of FastNAT is implemented in hardware, while other packet processing functions of the FastNAT are implemented in software.
  • the diagram 600 illustrates the interaction of HNAT (hardware) and FastNAT (remaining functions implemented in software) of the mixed accelerator.
  • the mixed accelerator may run on a designated hardware platform, and may support all packets (special provisions may be made for certain types of packets, for example ALG and fragmented packets). For supported packets (packet types; e.g.
  • the NAT entry may be added to a FastNAT table and hardware NAT table, for support by both FastNAT and HNAT.
  • the packet(s) may undergo NAT in hardware, and have mangle and routing performed by FastNAT, therefore bypassing the OS network stack.
  • unsupported packets e.g. ALG and fragmented packets
  • Other packets may undergo NAT, routing, and mangle in FastNAT, thus not being processed through the OS network stack.
  • supported (and unsupported) packets may be processed by (or bypass, respectively) dedicated HNAT module 602 in a manner similar to that described with respect to HNAT module 402 in Fig. 4.
  • the packets are passed between SW driver Rx 614 and layer3 interface driver Rx 616, and between SW driver Tx 634 and layer3 interface driver Tx 632.
  • SW driver Rx 614 may mark the SKB with NAT/ ACL information according to the received descriptor
  • SW driver Tx 634 may mark the sent descriptor with the NAT/ ACL info according to the sent SKB.
  • the FastNAT component 618 of the mixed accelerator may process packets incoming from the layer3 interface Rx driver 616.
  • FastNAT 618 may search the previously established FastNAT table to see if there is a match for the packet (i.e. to determine if the packet hits). If the packet hits, FastNAT 618 may perform the following operations:
  • FastNAT 618 may provide the packet to the layer3 interface Tx driver 632.
  • the packet may be provided to the OS network stack, where it may go through the prerouting point 620, where connection tracking, mangle, and DST NAT may be performed. From there, the packet may go through routing 622. For local destination, the packet is routed to local in 626, where mangle and filtering may be performed, the packet moving to the local out point 628, where mangle and filtering may again be performed before providing the packet to postrouting point 630. For non-local destinations, the packet goes through forward point 624 where mangle and filtering may be performed before providing the packet to postrouting point 630.
  • FastNAT may add a FastNAT entry for supported connections, when a connection is established.
  • FastNAT may also add respective DST NAT and SRC NAT entries for the connection, one in the original direction of the packet, one in the reply direction of the packet, and may further add ACL, route, and mangle decision information to the FastNAT entry.
  • the entry is supported in hardware, it may also be added in hardware.
  • an HNAT module may support 512 uplink NAT connections and 512 downlink NAT connections, and 128 Firewall ACL (Access Control List) entries: 64 Ingress (incoming) entries and 64 Egress (outgoing) entries. Both the NAT rules and Firewall rules may be maintained in respective, different tables, similar in design.
  • hardware acceleration may be provided for specific supported packets or packet types. Thus, in one set of embodiments, only simple NATs may be programmed in the hardware NAT table.
  • ALG Application-Level Gateway
  • the packets may be processed by the CPU (OS NAT code), i.e. by the kernel components shown in Fig. 1, for example.
  • OS Firewall code i.e. by the kernel components shown in Fig. 1, for example.
  • the packets may be processed through the CPU (OS Firewall code) for cases were deep packet inspection is involved.
  • One embodiment of a possible Firewall table is shown in Fig. 7 for illustration purposes.
  • Ingress and egress ACLs may have the same structures, but separate enables.
  • ACL rules may be designed as a combination of the entries, each of which may be a combination of the command-data (CMD_DATA) and operation code (OPCODE) structure.
  • CMD_DATA command-data
  • OPCODE operation code
  • More entries may be added to a rule by setting the link to 1, and pointing to the next entry with a next entry point.
  • the associated CMD_DATA may be interpreted as described in the table shown in Fig. 8, according to one embodiment.
  • CMD_DATA may be part of the same sequence as the OPCODE.
  • NAT ingress table 900 may represent the structure of NAT ingress table 606 from Fig. 6 (and similarly, of NAT ingress table 406 from Fig. 4), and NAT egress table 950 may represent the structure of NAT egress table 608 from Fig. 6 (and similarly, of NAT egress table 408 from Fig. 4).
  • the Key entry in the NAT table may be used to match the packet, and the Info entry in the NAT table may be used to edit the packet when there is a packet match according to the Key entry.
  • Each entry may have an associated free-running ager timer's timestamp field.
  • the timestamp for the entry may be updated with the current timestamp.
  • the hardware may periodically scan all timestamp entries, and age out the ones that exceeded their limits.
  • the ingress (incoming) packet flow is illustrated by diagram 1000 of Fig. 10.
  • the top portion of diagram 1000 shows the packet flow as the packet is processed by HNAT module 1002, which represents the hardware accelerator for offloading NAT from the system CPU (and consequently from the OS kernel/network stack).
  • HNAT module 1002 represents the hardware accelerator for offloading NAT from the system CPU (and consequently from the OS kernel/network stack).
  • the received packet is parsed and it is determined whether the packet is supported (1004). If the packet is not supported, it is passed on to the software driver Rx, which may set the SKB flags according to the descriptor NAT status (1026). If the packet is supported, the ACL ingress table (e.g. ACL ingress table 404 shown in Fig. 4) is traversed to match the packet to the appropriate entry (1006).
  • ACL ingress table e.g. ACL ingress table 404 shown in Fig. 4
  • the NAT ingress table (e.g. NAT ingress table 406 shown in Fig. 4) is traversed to match the packet to the appropriate entry (1008).
  • the ACL and NAT status is updated in ingress packet control (1010). It is then determined whether there is a match for an ACL entry (1012). If there is a match, it is determined whether the packet should be dropped (1014). If the packet ought to be dropped, it is dropped (1016). If there is no ACL match, or there is an ACL match but the packet is not to be dropped, it may be determined whether the packet matches a NAT entry (1018).
  • a destination network address translation is performed on the packet (1020), and the descriptor NAT status is updated (1022).
  • the descriptor NAT status is also appropriately updated if the packet does not match a NAT entry.
  • the processed packet is then sent to the software driver Rx for further processing (1026).
  • the bottom portion 1024 of Fig. 10 shows netfilter processing within the OS kernel, detailing various steps related to the HNAT functionality.
  • it may be determined whether a connection has been established (1032). If a connection has been established, and the packet is not an ALG packet (1034) and is not a PPP (Point-to-Point - 1036) packet, a NAT entry is added to hardware (1038).
  • the RSC NAT is performed (1052), and the packet is sent to the WLAN or LAN interface (1054).
  • the packet structure for start address, packet size, and next packet descriptor is shown in the table 1100 of Fig. 11.
  • the software may examine the descriptor status field. Once it has detected that the ownership bit has been cleared, it may examine the status fields to determine whether software-based NAT is required, or NAT has already been performed for the packet by HNAT.
  • NAT_STATUS bit the hardware NAT was successful. If the NAT_STATUS bit is not set, software is instructed to perform NAT for this packet. If FRG is set, it indicates that the packet was fragmented. If NATJJNSUPPORTED is set, it indicates that HNAT did not recognize the packet type. If NAT_UNSUPPORTED is 0, it may indicate that this packet had no NAT entry, resulting in the CPU processing the packet, then building the NAT table if applicable. The hardware accelerator driver may set HW NAT status flags on the socket buffer (SKB), so the OS netfilter may determine whether software NAT is to be performed or skipped.
  • SKB socket buffer
  • Software may create the HW NAT entry when software NAT is performed.
  • the creation of the entry may be dependent on the following constraints: new TCP connections are established, an ingress UDP data connection is known, and an ICMP ping request is sent out with packets expected at ingress.
  • Both the DST NAT entry and SRC NAT entry for one connection may be added once the above requirements have been met. Ipv4 TCP, UDP and ICMP connections may all be supported in this mode.
  • the egress (outgoing) packet flow for HNAT is illustrated by the diagram of Fig. 12.
  • the bottom portion 1224 of Fig. 12 shows processing within the OS kernel, detailing steps related to HNAT functionality.
  • the packet may be received from WLAN or LAN interface (1226).
  • connection tracking it may be determined whether a connection has been established (1238). If a connection has been established, and the packet is not an ALG packet (1240) and is a PPP packet (1242), a NAT entry is added to hardware (1244). It may also be determined if there is a NAT entry in hardware (1246), and as a consequence the SKB may be marked with hardware SRC NAT (1248).
  • the software may perform the DST NAT (1232).
  • the RSC NAT is performed (1262), and the packet is sent to the driver software Tx, which may set the descriptor NAT status according to the SKB flags (1227).
  • Fig. 1200 shows the packet flow as the packet is processed by HNAT module 1202, which represents the hardware accelerator for offloading NAT from the system CPU (and consequently from the OS kernel/network stack).
  • HNAT module 1202 represents the hardware accelerator for offloading NAT from the system CPU (and consequently from the OS kernel/network stack).
  • the packet is received through the driver Tx (1227).
  • a NAT status may be obtained from the descriptor within the packet, and it may be determined if an SRC NAT needs to be performed (1204). If not, the packet is sent on from module 1202. If SRC NAT is to be performed, the packet is parsed and it is determined whether the packet is supported (1206). If the packet is not supported, it is sent on from module 1202. If the packet is supported, the ACL egress table (e.g.
  • ACL egress table 410 shown in Fig. 4 is traversed to match the packet to the appropriate entry (1210).
  • the NAT egress table e.g. NAT egress table 408 shown in Fig. 4
  • the ACL and NAT status is updated in egress packet control (1212). It is then determined whether there is a match for an ACL entry (1214). If there is a match, it is determined whether the packet should be dropped (1216). If the packet ought to be dropped, it is dropped (1222). If there is no ACL match, or there is an ACL match but the packet is not to be dropped, it may be determined whether the packet matches a NAT entry (1218). If the packet matches a NAT entry, a source network address translation is performed on the packet (1220), and the processed packet is passed on from module 1202.
  • HNAT may be designed to support ipv4 TCP, UDP and ICMP packets, for example.
  • Software may already have knowledge of whether HNAT supports the packet, and software may therefore disable HNAT when transmitting unsupported packets. Furthermore, software may add a NAT entry before transmitting supported packets. Software may also be used to disable hardware based NAT when transmitting fragmented packets.
  • Fig. 15 shows a diagram 1500 illustrating packet flow for a FastNAT module according to one embodiment.
  • Diagram 1500 highlights operation of a FastNAT module, which may be implemented as a software accelerator receiving and transmitting packets from and to layer3 interface driver.
  • the packet flow illustrated in Fig. 15 is, however, representative of the operation of a FastNAT module in general, and is not restricted to software implementations thereof.
  • One embodiment of the structure for a FastNAT table used by a FastNAT module is shown in Fig. 14, for illustration purposes.
  • FastNAT may forward packets such that the packets bypass the OS kernel netfilter process, and thus bypass routing in the OS kernel.
  • FastNAT may be set up to forego processing fragmented packets and ALG packets, to allow these packets to process through the OS kernel normally.
  • a hook may be established at the postrouting point of the OS kernel netfilter process when the FastNAT module is loaded.
  • a FastNAT entry may be added when a new TCP connection is established, or ingress UDP data connection is known.
  • the first packet in the new stream may go through the OS kernel netfilter process, where at the postrouting point FastNAT may create a NAT table entry.
  • FastNAT may be configured to support TCP and UDP connections, among others.
  • a packet may process through the OS kernel as per normal operation, and a FastNAT entry may be added by the postrouting hook for this new connection.
  • Every NAT entry may have a timer, which may be reset when the NAT entry results in a packet hit.
  • the NAT entry may be removed when its timer expires (i.e. times out). Firewall in FastNAT
  • an IP address and a port number may be used to filter packets.
  • a port number e.g. a layer4 port may be used to filter packets.
  • the OS kernel netfilter process may also use this information to track connections, it is already known if a connection needs to be filtered when it is created. This ACL decision may be added into the FastNAT entry to avoid requiring unnecessary matching in the Netfilter filter table.
  • a packet may arrive through a layer3 interface driver Rx (1504), and FastNAT may determine whether the packet is supported (1508). If the packet is supported, FastNAT matches the NAT table with the packet's protocol, source IP, destination IP, source port, and destination port (1510). Referring back to Fig. 14, these packet properties may all be part of a key entry in the FastNAT table. If there is no hit, or when the packet is not supported, the packet may be passed on by FastNAT to be processed through the OS kernel netfilter as the packet would ordinarily be processed (1524). If the packet is a match for one of the FastNAT table entries, FastNAT may determine if the packet is to be dropped (1516), and if the packet is to be dropped, FastNAT drops the packet (1518).
  • FastNAT fetches information from the corresponding FastNAT entry (i.e. the entry that the packet hit), and modifies the packet with the information fetched from the info section of the corresponding FastNAT entry (1512).
  • info entry is shown in the table of Fig. 14.
  • the checksum may also be recalculated after the packet has been modified.
  • the timer of the respective entry may be also updated for each hit.
  • a NAT may then be performed (1514), and the output interface selected (1520). From there, the packet may be provided to the layer3 interface driver Tx for transmission (1522).
  • FastNAT may be configured to support ipv4 TCP and UDP connections.
  • FastNAT may determine if the packet is supported (1538), and if it is, it may check to see if SRC NAT has been performed (1546), and also check to see if DST NAT has been performed (1540).
  • a FastNAT entry may be added when a new TCP connection is established or ingress UDP data connection is known.
  • FastNAT may add two entries for one connection. A first entry may be added in ingress for a destination NAT, and a second entry may be added in egress for a source NAT. The entry may be removed when its timer expires. For example, as shown in Fig.
  • FastNAT may forward packets between layer3 interfaces.
  • the incoming and outgoing interfaces may be layer3 interfaces rather than layer2 interfaces.
  • the routing module When the first packet of a connection arrives at postrouting, its routing decision may have already been made by the routing module, and information corresponding to the output interface may be added into the FastNAT entry.
  • the packet may be forwarded to the output interface in the FastNAT module.
  • the output interface may be on a list of layer3 interfaces if the packet belongs to a multicast stream.
  • a packet is classified based on MAC, VLAN, IP, port, and DSCP. Normally this information does not change during a connection, which means that classified results may remain the same for one connection. Therefore, re-marked DSCP, re-marked SKB priority, and mark may be added into the FastNAT entry when adding a new FastNAT entry. DSCP, SKB priority, and mark may be modified when forwarding a packet in FastNAT. FastNAT may forward packets between layer3 interfaces, but QoS may be guarded on layer2 interface, in order for FastNAT to not affect the QoS.
  • a mixed accelerator may combine an HNAT module and a FastNAT module to process packets, the packets thereby not having to be handled in the communication stack software running in the OS kernel.
  • NAT may be performed by the HNAT module, while mangle and other functions may be performed in software, outside the OS kernel. Packets may be forwarded by FastNAT, thus not being processed through the OS network stack.
  • NAT and mangle may both be performed by FastNAT, and the packets may also be forwarded by FastNAT and not be processed through the OS network stack. Fragmented packets and other unsupported packets may be processed through the OS network stack as per normal operation.
  • the packet flow for a mixed accelerator is shown in Fig. 16.
  • the top portion of diagram 1600 shows the packet flow as the packet is processed by HNAT module 1602, which represents the hardware accelerator portion of the mixed accelerator.
  • the received packet is parsed and it is determined whether the packet is supported (1604). If the packet is not supported, it is passed on to the software driver Rx (1628). If the packet is supported, the ACL ingress table (e.g. ACL ingress table 404 shown in Fig. 4) is traversed to match the packet to the appropriate entry (1608). Similarly, the NAT ingress table (e.g. NAT ingress table 406 shown in Fig. 4) is traversed to match the packet to the appropriate entry (1610).
  • ACL ingress table e.g. ACL ingress table 404 shown in Fig. 4
  • the NAT ingress table e.g. NAT ingress table 406 shown in Fig.
  • the ACL and NAT status is updated in ingress packet control (1616). It is then determined whether there is a match for an ACL entry (1618). If there is a match, it is determined whether the packet should be dropped (1620). If the packet ought to be dropped, it is dropped (1622). If there is no ACL match, or there is an ACL match but the packet is not to be dropped, it may be determined whether the packet matches a NAT entry (1612). If the packet matches a NAT entry, a destination network address translation is performed on the packet for ingress or a source network address translation is performed on the packet for egress (1614), and the descriptor NAT status is updated (1606). The descriptor NAT status is also appropriately updated if the packet does not match a NAT entry. The processed packet is then sent to the software driver Rx for further processing (1628).
  • FastNAT may determine whether the packet is supported (1508). If the packet is supported, FastNAT matches the FastNAT table with the packet's protocol, source IP, destination IP, source port, and destination port (1634). If there is no hit, or when the packet is not supported, the packet may be processed through the OS kernel as it would be processed ordinarily, and DST NAT may be performed at the prerouting point if needed (1646). If the packet is a match for one of the FastNAT entries, FastNAT may determine if the packet is to be dropped (1640), and if the packet is to be dropped, FastNAT drops the packet (1642).
  • FastNAT fetches information from the matched (hit) FastNAT entry, and modifies the packet with the information fetched from the matched FastNAT entry (1636).
  • a DST NAT is then performed if it was not previously performed by HNAT 1602, or an SRC NAT is performed if it cannot be performed by HNAT module 1602 (1638).
  • FastNAT selects the output interface (1644), and provides the packet to the layer3 interface driver Tx for transmission (1630).
  • FastNAT may determine if the packet is supported (1660), and if it is, it may check to see if SRC NAT has been performed (1668), and also check to see if DST NAT has been performed (1662). If SRC NAT has been performed in the original direction (1670 - Yes), an SRC NAT entry is added (1664). If SRC NAT has been performed but not in the original direction (1670 - No), a DST NAT entry may be added (1672). Similarly, if DST NAT has been performed in the original direction (1666 - Yes), a DST NAT entry is added (1672). If DST NAT has been performed but not in the original direction (1666 - No), an SRC NAT entry may be added (1664). Also at the postrouting point, SRC NAT may be performed if needed.
  • a NAT entry may be written in hardware, and an ACL entry may also be written in hardware. Details for these entries were previously described with reference to the Firewall table and NAT table corresponding to HNAT. For packets supported only by FastNAT, a NAT entry may be written in the FastNAT driver. Details for these entries were previously described with reference to the FastNAT table corresponding to the FastNAT accelerator.
  • ACL may be performed in hardware, obviating the need for ACL in FastNAT.
  • ACL may be performed by the FastNAT driver when FastNAT is forwarding the packet.
  • an IP address and layer4 port may be used to filter the packets.
  • the OS kernel netfilter process may also use this information to track the connection, it is already known if a connection should be filtered when it is created.
  • the ACL decision may be added into the FastNAT entry to avoid unnecessary matching in the netfilter filter table.
  • ACL may be performed in the netfilter filter table, which represents the normal operating flow (i.e. without acceleration).
  • NAT may be performed by HNAT, obviating the need for performing NAT in FastNAT.
  • NAT may be performed by FastNAT when FastNAT is forwarding the packet.
  • FastNAT may match the contents of the packets against entries in the FastNAT table for the packet's protocol, source IP, destination IP, source port, and destination port. If the packet matches a FastNAT entry, FastNAT may fetch information from the matched FastNAT entry, and modify the packet with the fetched information. The checksum may also be recalculated after modifying the packet. The timer of the entry may be updated for each hit.
  • a FastNAT entry may be added when a TCP connection is established, or an ingress UDP data connection is known. If the connection is also supported by the HNAT, the NAT entry may also be added into hardware. FastNAT may add two entries for one connection, with one entry added in ingress for destination NAT, and another entry added in egress for source NAT. The entry may be removed when its timer expires.
  • NAT may be performed in the OS kernel netfilter NAT table, representing normal operating mode (i.e. without acceleration).
  • OS kernel netfilter NAT table representing normal operating mode (i.e. without acceleration).
  • Routing is performed by FastNAT.
  • FastNAT may forward packets between layer3 interfaces.
  • the output interface may also be added into the FastNAT entry.
  • the packet may simply be forwarded to the output interface by FastNAT.
  • the output interface may be on a list of layer3 interfaces if the packet belongs to a multicast stream.
  • the packet is classified based on MAC, VLAN, IP, port, and DSCP. Normally, this information does not change for one connection, so the classification result may remain the same for one connection. Accordingly, re-marked DSCP, remarked SKB priority, and mark may be added into the FastNAT entry when creating a new FastNAT entry. DSCP, SKB priority, and mark may be modified when forwarding the packet in FastNAT. FastNAT may forward packets between layer3 interfaces, but QoS may be guarded on layer2 interfaces, such that FastNAT does not affect the QoS.
  • certain changes may be made to the OS kernel for implementing HNAT.
  • OS kernel changes may be made for adapting the OS to HNAT.
  • Applicable NAT entries (see above) added using the IPtable command may be programmed in the HNAT table using the format described with respect to the FastNAT accelerator (see the description for the FastNAT section above).
  • the checkentry function of the HNAT table may target SRC NAT, and DST NAT may be changed to add the applicable entry in the hardware ingress/egress NAT table.
  • MASQUERADE target there may not be any changes in the checkentry function. Instead the changes may be implemented in the target callback function in the MASQUERADE module, and the applicable NAT entries may be added to the hardware ingress/egress NAT table. Similarly, the destroy callback function may be modified to delete the entries from the hardware ingress/egress NAT table.
  • Applicable firewall entries (see above) added using the IPtable command may be programmed in the hardware firewall table using the format described with respect to the HNAT (see the description for the HNAT section above). For this to happen, the checkentry function of the TCP, UDP, ICMP, ToS, etc., matches, along with the ACCEPT, DROP, and JUMP targets may be programmed in the hardware ingress/egress Firewall table. Similarly, the destroy callback function may be modified to delete the entries from the hardware ingress/egress Firewall table.
  • FastNAT may be implemented in hardware.
  • FastNAT may create a FastNAT table entry, identifying the packet according to a key, which includes the packet's protocol, source IP, destination IP, source port, and destination port.
  • the FastNAT entry may also include information associated with the key. This information may include accept/drop, NAT IP address, NAT port, output interface, DSCP, priority, and mark.
  • Packets may be routed to the FastNAT module/function(s) by the layer3 interface driver, and if a packet hits one of the entries in the FastNAT table (based on the key), the packet may be processed by FastNAT, and therefore bypass the OS kernel netfilter. Once it has processed the packet, FastNAT may provide the processed packet to the layer3 interface driver. This allows the packet to bypass the OS kernel netfilter framework.
  • FastNAT may perform NAT, firewall, and Mangle (QoS) functionality. In one set of embodiments, FastNAT may perform ACL check, mangle, NAT (if needed), and routing to select appropriate layer3 output interface.
  • FastNAT Some or all of the functions of FastNAT described above may be implemented in software or hardware or a combination of both, one example of which is the HNAT/FastNAT mixed accelerator described above with reference to Fig. 16.
  • various other hardware implementations of FastNAT are also possible and are contemplated.
  • certain CPU-intensive functions of the FastNAT module may be implemented in hardware. For example, checksum calculation, hash FastNAT table lookup, and packet modification may be performed by a hardware module/circuit, as opposed to those functions being performed by a FastNAT driver executed by the CPU.
  • This hardware module/circuit may be designed to interoperate with the FastNAT driver.
  • it may be operated in addition to an HNAT module in a mixed accelerator, which may otherwise operate as described above.
  • FastNAT may be implemented as a hardware module, as shown in Fig. 17.
  • a system on chip (SOC) 1702 includes Gigabit MAC interfaces (GMACs) GMAC0-GMAC4 (1714-1720), which are coupled to a FastNAT module 1712.
  • GMACs gigabit MAC interfaces
  • FastNAT module 1712 is a hardware module, which may perform ACL, QoS and PPPoE functions, among others.
  • SOC 1702 further includes WiFi-ETH4 module 1708, USB-ETH5 module 1706, and Virtual ETH6 module 1704, which operate as layer3 virtual interfaces in the OS (e.g.
  • WiFi-ETH4 module 1708 is a NIC (network interface controller) interface connected to a WiFi module via PCI bus.
  • USB-ETH5 module 1706 is a NIC interface connected to an Ethernet dongle via USB.
  • Virtual ETH6 module 1704 is a NIC interface connecting to other virtual NIC interfaces.
  • the FastNAT module 1712 is connected between CPU 1710 and each GMAC interface, as shown.
  • FastNAT module 1712 may be operated with a virtual Ethernet interface in the OS, e.g. in the Linux OS, to receive and transmit Ethernet packets. For each packet, FastNAT module 1712 may insert two additional bytes in the packet header. The first byte (ByteO) may be an Operation Code, and the second byte (Bytel) may be an Interface Index. According to one embodiment, the values of ByteO and Bytel may be respectively assigned as follows:
  • OxFF Not a valid interface. It means the packet does not match a FastNAT table entry, and will go through the OS kernel process, including netfilter, firewall and routing
  • FastNAT module 1712 may process four types of packets.
  • the first packet type may represent packets intended from one GMAC interface to another GMAC interface. If an incoming packet from one of the GMAC interfaces 1714-1720 (a source GMAC interface) is intended for another one of the GMAC interfaces 1714-1720 (a destination GMAC interface), and the packet hits one of the entries in the FastNAT table, the packet is forwarded by FastNAT module 1712 to the destination GMAC interface.
  • the second packet type may represent packets intended from a GMAC interface to one of the Virtual Ethernet Interfaces (VEIs).
  • VIs Virtual Ethernet Interfaces
  • FastNAT module 1712 transfers the packet to the appropriate VEI Ethernet driver, and starts a DMA to transmit the packet. As part of the DMA, the packet is transferred to memory 1722, from which it is then transferred to the destination VEI. If the packet does not hit one of the entries in the FastNAT table, it is processed by the OS kernel, as its desired target may be local CPU 1710.
  • the third packet type may represent packets intended from a VEI to a GMAC interface.
  • an incoming packet is transferred to the FastNAT Ethernet driver by starting a DMA.
  • the packet is routed, and NAT is performed on the packet by FastNAT module 1712 if necessary.
  • the processed packet is directly forwarded to the destination GMAC interface.
  • the packet is transferred to memory 1722 from the receiving VEI, and then transferred to the destination GMAC interface from memory 1722.
  • the fourth packet type may represent packets intended from one of the VEIs 1704-1708 (source VEI) to another VEI (destination VEI).
  • an incoming packet is transferred to the FastNAT Ethernet driver by starting a DMA.
  • the packet is routed, and NAT is performed on the packet by FastNAT module 1712 if necessary.
  • the processed packet is returned and transferred to the real target according to the first two bytes in the packet header (e.g. to a destination VEI), or it is received by local CPU 1710 from FastNAT module 1712.
  • DMA transfers take place between FastNAT module 1712 and memory 1722, and between memory 1722 and VEI interfaces 1704-1708.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Pour les paquets reçus d'un réseau, une ou plusieurs opérations de traitement de paquets, telles que les opérations NAT (traduction d'adresse réseau) et pare-feu peuvent être déchargées du noyau du système d'exploitation (par ex. Linux) pour être confiées à un moteur matériel dédié, un pilote logiciel dédié ou à une combinaison des deux. Le résultat de la décharge de ces opérations est que les paquets n'ont plus à être traités par un logiciel de pile de communication fonctionnant dans un noyau du système d'exploitation, ce qui libère de la largeur de bande d'UC, laquelle peut être utilisée pour augmenter les performances d'autres modules logiciels applicables. Un module de décharge peut recevoir et émettre des paquets depuis et vers un logiciel pilote d'interface de couche 3, et tenir une table d'exécution contenant des informations sur les paquets. Lorsqu'un paquet est associé à une entrée de la table d'exécution, le module de décharge traite le paquet, ce qui empêche le logiciel de pile de communication de traiter le paquet, de sorte que le paquet contourne le processus Netfilter du noyau de l'OS.
PCT/CN2011/081785 2011-11-04 2011-11-04 Accélérateur nat/pare-feu WO2013063791A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/081785 WO2013063791A1 (fr) 2011-11-04 2011-11-04 Accélérateur nat/pare-feu

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/081785 WO2013063791A1 (fr) 2011-11-04 2011-11-04 Accélérateur nat/pare-feu

Publications (1)

Publication Number Publication Date
WO2013063791A1 true WO2013063791A1 (fr) 2013-05-10

Family

ID=48191221

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/081785 WO2013063791A1 (fr) 2011-11-04 2011-11-04 Accélérateur nat/pare-feu

Country Status (1)

Country Link
WO (1) WO2013063791A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104243631A (zh) * 2014-10-13 2014-12-24 北京太一星晨信息技术有限公司 一种IPv4地址与IPv6地址有状态转换的方法及设备
US20150222547A1 (en) * 2014-02-06 2015-08-06 Mellanox Technologies Ltd. Efficient management of network traffic in a multi-cpu server
US9363183B2 (en) 2014-04-10 2016-06-07 Cisco Technology, Inc. Network address translation offload to network infrastructure for service chains in a network environment
CN108234359A (zh) * 2016-12-13 2018-06-29 华为技术有限公司 传输报文的系统和方法
WO2018174946A1 (fr) * 2017-03-23 2018-09-27 Google Llc Routeur gigabit
CN109088957A (zh) * 2018-08-30 2018-12-25 京信通信系统（中国）有限公司 Nat规则管理的方法、装置和设备
US10176333B2 (en) 2014-09-18 2019-01-08 Samsung Electronics Co., Ltd. Token-based scheme for granting permissions
CN109450893A (zh) * 2018-11-05 2019-03-08 南京壹进制信息技术股份有限公司 一种基于linux内核的网络防护软件方法和系统
US10354077B2 (en) 2015-02-09 2019-07-16 Samsung Electronics Co., Ltd. Permission control method and electronic device operating the same
CN112511461A (zh) * 2020-11-06 2021-03-16 无锡江南计算技术研究所 一种面向申威平台的网络数据包的调度方法
EP3691225A4 (fr) * 2017-09-26 2021-05-26 Xi'an Zhongxing New Software Co., Ltd. Procédé et dispositif de transmission de paquet, et support de stockage lisible par ordinateur
CN112995025A (zh) * 2021-02-05 2021-06-18 杭州迪普科技股份有限公司 路径追踪方法、装置、设备及计算机可读存储介质
US11604656B2 (en) 2019-07-10 2023-03-14 Samsung Electronics Co., Ltd. Method and apparatus for managing application
US20230336472A1 (en) * 2022-04-19 2023-10-19 Mediatek Inc. Method and electronic device for saving power applied to a router

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040046260A (ko) * 2002-11-26 2004-06-05 한국전자통신연구원 ＮＡＴ 기능을 갖는 사설망에서 ＩＰＳｅｃ을 이용한종단과 종단 간의 ｐｒｉｖａｔｅ 정보 전송 방법 및 이를이용한 보안 서비스 방법
US20060190613A1 (en) * 2005-02-23 2006-08-24 International Business Machines Corporation Method, program and system for efficiently hashing packet keys into a firewall connection table
CN101605105A (zh) * 2009-07-14 2009-12-16 中兴通讯股份有限公司 一种对分片报文进行网络地址转换的方法及设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040046260A (ko) * 2002-11-26 2004-06-05 한국전자통신연구원 ＮＡＴ 기능을 갖는 사설망에서 ＩＰＳｅｃ을 이용한종단과 종단 간의 ｐｒｉｖａｔｅ 정보 전송 방법 및 이를이용한 보안 서비스 방법
US20060190613A1 (en) * 2005-02-23 2006-08-24 International Business Machines Corporation Method, program and system for efficiently hashing packet keys into a firewall connection table
CN101605105A (zh) * 2009-07-14 2009-12-16 中兴通讯股份有限公司 一种对分片报文进行网络地址转换的方法及设备

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150222547A1 (en) * 2014-02-06 2015-08-06 Mellanox Technologies Ltd. Efficient management of network traffic in a multi-cpu server
US10164905B2 (en) * 2014-02-06 2018-12-25 Mellanox Technologies, Ltd. Efficient management of network traffic in a multi-CPU server
US9363183B2 (en) 2014-04-10 2016-06-07 Cisco Technology, Inc. Network address translation offload to network infrastructure for service chains in a network environment
US10176333B2 (en) 2014-09-18 2019-01-08 Samsung Electronics Co., Ltd. Token-based scheme for granting permissions
CN104243631A (zh) * 2014-10-13 2014-12-24 北京太一星晨信息技术有限公司 一种IPv4地址与IPv6地址有状态转换的方法及设备
US10354077B2 (en) 2015-02-09 2019-07-16 Samsung Electronics Co., Ltd. Permission control method and electronic device operating the same
CN108234359A (zh) * 2016-12-13 2018-06-29 华为技术有限公司 传输报文的系统和方法
CN108234359B (zh) * 2016-12-13 2020-12-04 华为技术有限公司 传输报文的系统和方法
WO2018174946A1 (fr) * 2017-03-23 2018-09-27 Google Llc Routeur gigabit
EP3691225A4 (fr) * 2017-09-26 2021-05-26 Xi'an Zhongxing New Software Co., Ltd. Procédé et dispositif de transmission de paquet, et support de stockage lisible par ordinateur
US11356410B2 (en) 2017-09-26 2022-06-07 Zte Corporation Packet transmission method and device, and computer readable storage medium
CN109088957A (zh) * 2018-08-30 2018-12-25 京信通信系统（中国）有限公司 Nat规则管理的方法、装置和设备
CN109088957B (zh) * 2018-08-30 2022-03-25 京信网络系统股份有限公司 Nat规则管理的方法、装置和设备
CN109450893B (zh) * 2018-11-05 2021-03-16 南京壹进制信息科技有限公司 一种基于linux内核的网络防护软件方法和系统
CN109450893A (zh) * 2018-11-05 2019-03-08 南京壹进制信息技术股份有限公司 一种基于linux内核的网络防护软件方法和系统
US11604656B2 (en) 2019-07-10 2023-03-14 Samsung Electronics Co., Ltd. Method and apparatus for managing application
CN112511461A (zh) * 2020-11-06 2021-03-16 无锡江南计算技术研究所 一种面向申威平台的网络数据包的调度方法
CN112995025A (zh) * 2021-02-05 2021-06-18 杭州迪普科技股份有限公司 路径追踪方法、装置、设备及计算机可读存储介质
CN112995025B (zh) * 2021-02-05 2023-02-28 杭州迪普科技股份有限公司 路径追踪方法、装置、设备及计算机可读存储介质
US20230336472A1 (en) * 2022-04-19 2023-10-19 Mediatek Inc. Method and electronic device for saving power applied to a router
US11805054B1 (en) * 2022-04-19 2023-10-31 Mediatek Inc. Method and electronic device for saving power applied to a router

Similar Documents

Publication Publication Date Title
WO2013063791A1 (fr) Accélérateur nat/pare-feu
US7630368B2 (en) Virtual network interface card loopback fastpath
US9363183B2 (en) Network address translation offload to network infrastructure for service chains in a network environment
US7738457B2 (en) Method and system for virtual routing using containers
US8780836B2 (en) Network system, controller, and network control method
US8601567B2 (en) Firewall for tunneled IPv6 traffic
CN106487719B (zh) 经由分组中继使网络功能外部化的系统和方法
US9246800B1 (en) Interface for extending service capabilities of a network device
US9460289B2 (en) Securing a virtual environment
US9736057B2 (en) Forwarding packet fragments using L4-L7 headers without reassembly in a software-defined networking (SDN) system
US8559429B2 (en) Sequential frame forwarding
US7852843B2 (en) Apparatus and method for layer-2 to layer-7 search engine for high speed network application
US7107609B2 (en) Stateful packet forwarding in a firewall cluster
US20190089641A1 (en) Stateful Connection Tracking
US20160198025A1 (en) Network system and network flow tracing method
EP1392035A2 (fr) Procéde de filtrage de packets
CN108881328B (zh) 数据包过滤方法、装置、网关设备及存储介质
WO2012127886A1 (fr) Système de réseau et procédé de configuration de routage politique
KR20140143155A (ko) 네트워킹 장치 가상화를 위한 패킷 처리 오프로딩 기법
US9047416B2 (en) Communication control system, switching node, communication control method and communication control program including PCI express switch and LAN interface
US20090080418A1 (en) Tunneling apparatus and tunnel frame sorting method and its program for use therein
US20190215306A1 (en) Rule processing and enforcement for interleaved layer 4, layer 7 and verb based rulesets
US20080077694A1 (en) Method and system for network security using multiple virtual network stack instances
EP3292663B1 (fr) Acheminement de paquets
US8934489B2 (en) Routing device and method for processing network packet thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11874915

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11874915

Country of ref document: EP

Kind code of ref document: A1