CN112953829B

CN112953829B - Flexible parser in network device

Info

Publication number: CN112953829B
Application number: CN202011409501.7A
Authority: CN
Inventors: 阿维·乌尔万; 利奥尔·纳尔基斯; 诺姆·布洛克
Original assignee: Mellanox Technologies Ltd
Current assignee: Mellanox Technologies Ltd
Priority date: 2019-12-10
Filing date: 2020-12-04
Publication date: 2022-09-13
Anticipated expiration: 2040-12-04
Also published as: EP3836509A1; EP3836509B1; CN112953829A; US20210176345A1; US11258885B2

Abstract

One embodiment includes a network device comprising: a hardware parser for receiving data of a header portion of a packet, the header portion including respective headers; a parser configuration register for storing a default parsing configuration data set, wherein the at least one hardware parser is configured to parse the at least one header in response to the default parsing configuration data set, producing first parsed data; a packet processing engine to select a selected parsing configuration data set from a selection of parsing configuration data sets in response to the first parsing data, load the selected parsing configuration data set into the parser configuration registers, and wherein some of the hardware parsers are configured to parse respective ones of the headers in response to the selected parsing configuration data set, generate second parsing data, and process the packet in response to the second parsing data.

Description

Flexible parser in network device

Technical Field

The present invention relates to network devices and in particular, but not exclusively, to parsers.

Background

As a first step in deciding how to forward a given packet, a router (or other network device) typically parses the header portion of the packet, i.e., identifies the fields in the header portion that contain relevant information, and extracts information from these fields that will be used by the forwarding logic. This header parsing and other packet processing operations are typically performed by hardware logic and therefore lack the flexibility of software driven processing. In this case, handling new or custom packet headers and/or options (e.g., options in IPv4 headers) can be particularly challenging, as the selection of new or custom headers and optional records and their order may differ from packet to packet, as compared to the fixed structure of the basic header. Similar problems occur when parsing other protocol headers (which may include various options such as TCP headers).

US20190215384 to Kfir et al describes a communication device comprising a plurality of interfaces configured to connect to a network for receiving and transmitting data packets with respective packet headers comprising a basic header record and one or more optional records. The parse instruction specifies one or more types of the alternative records and indicates, for each specified type, an offset within the specified type of the alternative record. Upon receiving each packet, the routing logic parses a base header record in the packet, parses one or more alternate records to identify any alternate records of the one or more specified types, extracts header data from the identified alternate records at an offset indicated for the specified type, and processes and forwards the data packet to the network via the interface based on information parsed from the base header record and the extracted header data.

Disclosure of Invention

The present invention provides a network device according to an embodiment of the present disclosure, including: a hardware parser coupled to receive data of a header portion of a packet, the header portion including respective headers; a parser configuration register configured to store a default parsing configuration data set, wherein at least one of the hardware parsers is configured to parse at least one of the headers in response to the default parsing configuration data set, producing first parsed data; a packet processing engine coupled with the hardware parsers and configured to select a parsing configuration dataset from a selection of parsing configuration datasets in response to the first parsing data, cause the selected parsing configuration dataset to be loaded into the parser configuration registers, and wherein some of the hardware parsers are configured to parse individual ones of the headers in response to the selected parsing configuration dataset, generate second parsing data, and process the packet in response to the second parsing data.

Further in accordance with an embodiment of the present disclosure, the apparatus is configured as an interface to an egress port, wherein the packet processing engine is configured to forward the packet to a network node in a packet data network via the egress port in response to the second parsed data.

Still further in accordance with an embodiment of the present disclosure, the packet processing engine is configured to change data in the header portion in response to the second parsed data.

Additionally, in accordance with an embodiment of the present disclosure, the apparatus includes a cache memory configured to cache a selection of a resolver configuration data set including the selected resolver configuration data set, the packet processing engine configured to cause the selected resolver configuration data set to be loaded from the cache memory into the resolver configuration register.

Further, in accordance with an embodiment of the present disclosure, the hardware parser is configured to parse header portions of respective Virtual Network Functions (VNFs) having respective header parsing schemes in response to selected respective parsing configuration datasets of the parsing configuration datasets, the packet processing engine is configured to select a selected parsing configuration dataset from the selection of the parsing configuration datasets in response to the first parsing data being identified as associated with one VNF, some of the hardware parsers are configured to parse respective headers in the header according to one of the header parsing schemes of the one VNF in response to the selected parsing configuration dataset, and the packet processing engine is configured to forward the packet in response to the second parsing data.

Further in accordance with an embodiment of the present disclosure, the each VNF comprises at least one virtual machine.

Still further in accordance with an embodiment of the present disclosure, the packet processing engine is configured to forward the packet to a virtual machine in response to the second parsed data.

Further, in accordance with an embodiment of the present disclosure, the packet processing engine is configured to identify the one VNF from a network address included in the first resolution data.

Further in accordance with an embodiment of the present disclosure, the respective hardware parsers are configured to successively parse the header portion according to respective offsets in the header portion, some of the hardware parsers being configured to calculate the respective offsets in response to the selected parsing configuration data and the header portion.

Further in accordance with an embodiment of the present disclosure, the selected parsing configuration data set includes, for each of the hardware resolvers: a next header offset of a next header Identification (ID) in the header portion; and a next protocol table linking a next header ID with a next protocol, wherein a first one of the hardware resolvers is coupled to retrieve a next header offset of the first hardware resolver from the selected parsing configuration dataset in the resolver configuration register, retrieve the next header ID from the header portion in response to the retrieved next header offset, the header ID being located at the next header offset in the header portion, retrieve an identification of the next protocol to process from the next protocol table for the first hardware resolver from the selected parsing configuration dataset in response to the retrieved next header ID, and transmit the header portion to a second one of the hardware resolvers configured to parse the header portion according to the next protocol.

Still further in accordance with an embodiment of the present disclosure, the selected parsed configuration data set includes: for each of the hardware resolvers, at least one data extraction offset in a header portion for which data is to be extracted, a first one of the hardware resolvers configured to extract data from the header portion in response to the at least one data extraction offset of the first hardware resolver in the selected resolution configuration data set.

According to another embodiment of the present invention, there is also provided a network method including: receiving data of a header portion of a packet, the header portion including respective headers; storing a default parsing configuration data set in a parser configuration register; parsing at least one of the headers in response to the default parsing configuration data set, resulting in first parsed data; selecting a selected parsing configuration data set from a selection of parsing configuration data sets in response to the first parsing data; causing the selected resolver configuration data set to be loaded into the resolver configuration register; parsing each of the headers in response to the selected parsing configuration data set, resulting in second parsed data; and processing the packet in response to the second parsed data.

Further in accordance with an embodiment of the present disclosure, the method includes forwarding the packet to a network node in a packet data network via an egress port in response to the second parsed data.

Further, in accordance with an embodiment of the present disclosure, the method includes changing data in the header portion in response to the second parsed data.

Further in accordance with an embodiment of the present disclosure, the method includes caching a selection of a resolved configuration data set including the selected resolved configuration data set in a cache memory; and causing the selected resolver configuration data set to be loaded from the cache memory into the resolver configuration register.

Still further in accordance with an embodiment of the present disclosure, the method comprises: parsing header portions of respective Virtual Network Functions (VNFs) having respective header parsing schemes in response to respective ones of the selected ones of the parsing configuration data sets; selecting a selected parsing configuration dataset from the selection of parsing configuration datasets in response to the first parsing data being identified as associated with one VNF; parsing, in response to the selected parsing configuration data set, respective ones of the headers according to one of the header parsing schemes of the one VNF; and forwarding the packet in response to the second parsed data.

Further, according to an embodiment of the present disclosure, the respective VNFs include at least one virtual machine.

Further, in accordance with an embodiment of the present disclosure, the method includes forwarding the packet to a virtual machine in response to the second parsed data.

Further in accordance with an embodiment of the present disclosure, the method comprises identifying the one VNF from a network address included in the first resolution data.

Still further in accordance with an embodiment of the present disclosure, the method includes successively parsing the header portion according to respective offsets in the header portion; and calculating the respective offsets in response to the selected parsing configuration data and the header portion.

Additionally, according to an embodiment of the present disclosure, the selected parsing configuration data set includes: a next header offset of a next header Identification (ID) in the header portion; and a next protocol table linking the next header ID with the next protocol, the method further comprising: retrieving the next header offset from the selected parsing configuration dataset; retrieving the next header ID from the header portion in response to the retrieved next header offset, the header ID being located at the next header offset in the header portion; retrieving, from the selected parsing configuration dataset, an identification of a next protocol to process from the next protocol table in response to the retrieved next header ID; and parsing the header portion according to the next protocol.

Further, according to an embodiment of the present disclosure, the selected parsing configuration data set includes: at least one data extraction offset in a header portion for which data is to be extracted, the method further comprising extracting data from the header portion in response to the at least one data extraction offset of the first hardware parser in the selected parsing configuration data set.

Drawings

The invention will be understood by reference to the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of a network device constructed and operative in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram of a hardware parser in the device of FIG. 1 operating in accordance with an embodiment of the present invention;

FIG. 3 is a block diagram of a hardware parser accessing data from a parse configuration dataset, according to an embodiment of the invention;

FIG. 4 is a block diagram illustrating fields in the parse configuration data set of FIG. 3, according to an embodiment of the invention;

FIG. 5 is a flow chart of steps in a parsing method that includes the apparatus of FIG. 1; and

fig. 6 is a flow chart including steps in a method of operation of the apparatus of fig. 1.

Detailed Description

Overview

As previously mentioned, header parsing and other packet processing operations are typically performed by hardware logic, and thus lack flexibility in software-driven processing. In this case, handling new or custom packet headers and/or options can be particularly challenging, as the selection of new or custom headers and optional records and their order may differ from packet to packet, as opposed to the fixed structure of the basic header.

One possible response to this difficulty, which is typically employed in simpler devices, is to parse only the base header and skip options and other new or custom formats. Even if it is not necessary to parse all headers in order to comply with the relevant standard, certain network functions (such as network security and route monitoring) may not be supported if the headers are skipped.

Alternatively, the device may be configured to handle the required header format. However, this approach requires the device to have sufficient memory resources to hold all the header data extracted by the parser from the packets transmitted through the device. These requirements also increase the size and cost of the device.

Embodiments of the present invention address the above-mentioned problems by providing a network device that includes a flexible hardware parser. The flexible hardware parser is configured to parse a header of the header portion based on using the configuration data stored in the parsing register. Parsing configuration data may be updated as needed, providing flexibility such that a flexible hardware parser may be configured to parse different headers having different lengths and formats, even after the hardware of the network device has been manufactured.

The header portion may be successively passed to different hardware parsers that parse different headers of the header portion. The order of passage of header portions in different hardware parsers may be configured using parsing configuration data. Parsing configuration data may include data used by the flexible hardware parser to determine the length of each header, the new header to be processed after the current header, and thus which hardware parser should next receive the header portion for parsing, and which fields of the header should be extracted, for example.

The network device may also include a local hardware parser that may work with the flexible hardware parser. Typically, local hardware parsers are not configurable, but only parse the header type they are designed to parse. For example, there may be a local hardware parser to parse Media Access Control (MAC) headers and a flexible hardware parser to parse VXLAN headers.

Accordingly, each flexible hardware parser of a network device may be configured using the parsing configuration data set to parse the headers of different respective protocols.

The network device may need to process different types of packets according to different parsing schemes. For example, a network interface card may provide services for a server hosting multiple Virtual Machines (VMs). Each VM may use a custom parsing scheme. The header types of different schemes may exceed the number of flexible hardware parsers in the network device.

Embodiments of the present invention address the above problems by storing different sets of parsing configuration data in memory. The parsing configuration data set may be dynamically loaded into registers used by the flexible hardware parser according to the type of packet to be processed. For example, a network device receives a packet destined for VM 1. The header portion is parsed according to a default parsing configuration data set, resulting in parsing data (e.g., MAC address) indicating that the packet is destined for VM 1. The resolved configuration data set of VM1 is loaded into a register and the header portion is re-resolved according to the resolved configuration data set of loaded VM 1. The packet is processed using the data from the second parse, including directing the packet to VM 1. Thus, a first parsing may be performed according to a default parsing configuration data set, and then a second parsing may be performed according to a selected parsing configuration data set.

In some implementations, a hardware parser of a network device receives data that includes header portions of respective headers. The parser configuration register stores a default set of parse configuration data. In response to the default parsing configuration data set, the at least one hardware parser parses at least one of the headers, thereby generating first parsed data. The packet processing engine selects a parsing configuration data set from a selection of parsing configuration data sets in response to the first parsing data. The packet processing engine causes the selected parser configuration data set to be loaded into the parser configuration registers. At least some hardware parsers parse respective ones of the headers in response to the selected parsing configuration data set, thereby producing second parsed data. The packet processing engine processes the packet in response to the second parsed data, which may include forwarding the packet to a network node in the packet data network via an egress port in response to the second parsed data, and/or changing data in a header portion and/or forwarding to another device or node in response to the second parsed data.

In some embodiments, to allow for fast loading of configuration data into registers, the network device includes a cache memory to cache a selection of resolved configuration data sets to load from into registers.

Description of the System

Referring now to fig. 1, fig. 1 is a block diagram of a network device 10 constructed and operative in accordance with an embodiment of the present invention. Network device 10 may be any suitable device such as, but not limited to, a router, a switch, or a network interface card. The network device 10 includes at least one network interface 12 configured to function as at least an ingress port and at least one egress port for receiving packets from the packet data network 14 and transmitting packets to the packet data network 14.

Network device 10 also includes a buffer 16, a hardware parser 18, a packet processing engine 20, a controller 22, parser configuration registers 24, cache memory 26, match and action table 28, and an optional communication bus interface 30.

Packets received by the network interface 12 are stored in a buffer 16. A hardware parser 18, controlled by a controller 22, parses the header portion of the received packet, typically under the instruction of a packet processing engine 20. At least some of the hardware parsers 18 parse the header portions according to the data loaded into the parser configuration registers 24. The cache memory 26 caches a selection 32 of the resolver configuration data set, which is selectively loaded into the resolver configuration registers 24 from the cache memory 26 by the controller 22 under instructions from the packet processing engine 20.

The hardware parser 18 parses various headers included in the header portion of the packet and may optionally extract additional information from the header portion. The parsed information is stored in the buffer 16 for retrieval by the packet processing engine 20 and/or transmission to the packet processing engine 20. In some embodiments, the header portion is also sent by the hardware parser 18 to the packet processing engine 20. The operation of the hardware parser 18 and the selection 32 of the parsed configuration data set are described in more detail below with reference to fig. 2-6.

The packet processing engine 20 uses the match and action table 28 to determine how each packet should be processed based on the resolution information generated by the hardware parser 18. The match and action table 28 includes data to be matched against parsed information and associated actions to be performed when a match is found. The data to be matched may include any field from a packet, such as a MAC or IP address, security information, Transmission Control Protocol (TCP) data, User Datagram Protocol (UDP) data, virtual extensible local area network (VXLAN) data, Generic Routing Encapsulation (GRE) data, and generic network virtualization encapsulation (GENEVE) data, as examples only. These actions may include any suitable action or each matching action, such as, but not limited to, re-parsing the header portion using a different set of parsing configurations, sending the packet to a given network node 36 via packet data network 14, sending the packet to a server 34 connected to network device 10 via communication bus interface 30, modifying the header portion, adding a new header, and/or deleting a header, such as a VLAN or multi-protocol label switching (MPLS). The communication bus interface 30 may operate according to any suitable protocol, such as, but not limited to, the PCIe (peripheral component interconnect express) interface standard.

For example, if the MAC address in the header portion matches a given MAC address, the packet will be re-parsed by the hardware parser 18 after the parser configuration register 24 is loaded with the parsing configuration data set a. In this example, the packet processing engine 20 instructs the controller 22 to load the resolved configuration data set a from the cache memory 26 and to send the header portion or a link to the header portion in the buffer 16 to the hardware parser 18 so that the header portion can be re-resolved according to the resolved configuration data set a. By way of another example, if the parsed information includes data B, the packet is forwarded to server C via communication bus interface 30. By way of additional example, if the parsed information includes data D, then the header portion is modified. By way of yet another example, if the parsed information includes data E, a packet is sent back to the packet data network 14 on port F. One or more actions may be associated with a single match.

The functionality of the packet processing engine 20 is also described with reference to fig. 6. Indeed, some or all of the functionality of packet processing engine 20 may be combined in a single physical component or, alternatively, implemented using multiple physical components. These physical components may include hardwired or programmable devices, or a combination of both. In some embodiments, at least some of the functions of packet processing engine 20 may be performed by a programmable processor under the control of appropriate software. The software may be downloaded to the device in electronic form, for example, over a network. Alternatively or additionally, the software may be stored in a tangible, non-transitory computer readable storage medium, such as optical, magnetic, or electronic memory.

The function of the controller 22 is also described with reference to fig. 6. Indeed, some or all of the functionality of the controller 22 may be combined in a single physical component, or alternatively, implemented using multiple physical components. These physical components may include hardwired or programmable devices, or a combination of both. In some embodiments, at least some of the functions of the controller 22 may be performed by a programmable processor under the control of appropriate software. The software may be downloaded to the device in electronic form, for example, over a network. Alternatively or additionally, the software may be stored in a tangible, non-transitory computer readable storage medium, such as optical, magnetic, or electronic memory.

In some embodiments, the functionality of the controller 22 may be implemented in the packet processing engine 20.

In the example of fig. 1, network device 10 may be implemented as a network interface card for server 34. The server 34 may include a plurality of Virtual Network Functions (VNFs) 38. Each virtual network function 38 may include one or more Virtual Machines (VMs). The hypervisor running on the server 34 may implement a VM. In some examples, different VMs may be operated for different guests, each with its own parsing and packet processing requirements. Each client may wish to be able to configure the hardware resolver 18 of the network device 10 according to their own requirements. However, due to the limited number of hardware parsers 18, the hardware parsers 18 cannot be programmed with a single set of parsing configuration data to parse data of different customers according to customer needs. When a packet is received in the buffer 16, the hardware parser 18 parses at least some of the header portions according to a default parsing configuration data set. The packet processing engine 20 uses the match table and the action table 28 to determine what action should be performed. One action may include re-parsing the header portion using a particular parsing configuration data set for the guest or VM associated with the header portion. For example, a MAC address included in a header portion may indicate a VM associated with the header portion.

Referring now to FIG. 2, FIG. 2 is a block diagram of the hardware parser 18 in the device 10 of FIG. 1 operating in accordance with an embodiment of the present invention. Hardware parser 18 includes a flexible hardware parser 40 and optionally one or more local hardware parsers 42, as shown in FIG. 2. The flexible hardware parser 40 is configured to parse header portion data from data in the parser configuration registers 24. Thus, hardware parser 40 is reconfigurable even after network device 10 has been manufactured. On the other hand, the local hardware parser 42 is typically not reconfigurable after the network device 10 is manufactured. For example, one of the local hardware resolvers 42 may be configured to resolve MAC headers, another local hardware resolver 42 may be configured to resolve multiprotocol label switching (MPLS) headers, and another local hardware resolver 42 may be configured to resolve User Datagram Protocol (UDP) headers. The local hardware resolvers 42 may be connected together in a fixed order as shown in fig. 2, such that when one of the local hardware resolvers 42 completes the parsing of a header portion (e.g., one of the headers), the header portion is passed to the next local hardware resolver 42 queued via one of the connections 46. Additionally or alternatively, each local hardware parser 42 may be connected to one or more (typically each) flexible hardware parsers 40 via connections 44. For example, after one of local hardware resolvers 42 completes parsing a portion of a header portion (e.g., one of the headers), the header portion is passed to one of flexible hardware resolvers 40 via one of connections 44. The flexible hardware resolvers 40 are also connected to each other via connections 44 such that when one of the flexible hardware resolvers 40 finishes parsing a portion of a header portion (e.g., one of the headers), the header portion is passed to another flexible hardware resolver 40 via one of the connections 44. The data in the parser configuration registers 24 may be used to configure the connection 44 between the hardware parsers 40, 42 (i.e. which

parser

40, 42 will receive the header portion to be processed next). For example, the identity of the connection 44 used to send the header portion to the

next parser

40, 42 may be included in the data stored in the parser configuration register 24. For a given configuration of the

hardware resolvers

40, 42, some connections 44 may be enabled while others are disabled. The configuration of the connection 44 is described in more detail with reference to fig. 3 to 5.

In some embodiments, one of the flexible hardware resolvers 40 may be configured as a zero-length parser, described in more detail below with reference to fig. 4, whereby the flexible hardware parser 40 is used to pass header portions between two local hardware resolvers 42 without actually parsing any header portions.

The order in which the header portions are passed between the

hardware parsers

40, 42 is determined by the order of the headers in the header portions. For example, if the header portion includes a MAC header followed by an Internet Protocol (IP) header followed by a UDP header followed by a virtual extensible local area network (VXLAN) header, the

hardware parser

40, 42 and its connection 44 are configured to parse the MAC header followed by the IP header followed by the UDP header followed by the VXLAN header. In some embodiments, the header portion may include more than one specific header protocol. For example, when tunneling is employed, there may be two MAC headers. In this case, the same flexible hardware parser 40 or local hardware parser 42 may be used to parse both MAC headers at different times in the parsing process. Alternatively, each MAC header may be parsed by a different one of the

hardware parsers

40, 42. The tunnel is described in more detail below with reference to fig. 4.

Referring now to FIG. 3, FIG. 3 is a block diagram of a flexible hardware parser 40, the flexible hardware parser 40 accessing data from a parse configuration data set 48, in accordance with an embodiment of the present invention. FIG. 3 shows that the resolver configuration data set 48 is currently loaded into the resolver configuration registers 24. The parsing configuration data set 48 includes a plurality of data subsets 50. Each of the data subsets 50 is used to configure each flexible hardware parser 40. For example, flexible hardware parser 40-1 is configured according to data in data subset 1, flexible hardware parser 40-2 is configured according to data in data subset 2, flexible hardware parser 40-3 is configured according to data in data subset 3, and flexible hardware parser 40-4 is configured according to data in data subset 4.

Referring now to FIG. 4, FIG. 4 is a block diagram illustrating fields in the resolved configuration data subset 1 (reference numeral 50) of FIG. 3, according to an embodiment of the invention.

The data subset 50 may include a header size field (not shown) that gives the size of the header that the flexible hardware parser 40-1 is configured to parse. This field may be useful when the headers parsed by flexible hardware parser 40-1 all have the same length. Alternatively, the data subset 50 may include a header size offset field 52 that provides an offset to the "header size field" in the header that the flexible hardware parser 40-1 is configured to parse. The "header size field" in the header provides the size of the header. The header size offset is not an absolute offset from the beginning of the header portion, but a relative offset from the beginning of the current header to be parsed. The data subset 50 may optionally include a header size mask field 54 that gives the number of bits included in the header size field in the header.

The data subset 50 may include a next header field 56, the next header field 56 giving an identification of the next header to be parsed in the header portion. This field may be useful when there is only one option for the next header of the current header. Alternatively, the data subset 50 may include a next header offset field 58 and a next header mask field 60. The next header offset field 58 provides a relative offset of the next header identification field in the header, giving the identification of the next header to be parsed in the header section. The data subset 50 may also include a next protocol table 62 that maps a next header identification with a protocol. The protocol value found in the next protocol table 62 may provide an identification of one of the connections 44 (FIG. 2) connecting the current flexible hardware parser 40 and the

other hardware parser

40, 42. The "next header" field is described in more detail with reference to fig. 5. The next header mask field 60 provides the number of bits included in the next header identification field in the header.

The data subset 50 may include a data extraction offset field 64, the data extraction offset field 64 giving an offset in the header of the data to be extracted. The data subset 50 may include a data extraction mask field that provides the number of bits to extract at the offset.

The data subset 50 may include a zero size field 66 indicating whether the flexible hardware parser 40-1 is a zero size parser. As described above, a zero-size parser may be used to pass header portions between two local hardware parsers 42 (or any two parsers) without any further processing of the packet.

The data subset 50 may include a tunnel behavior field 68. As described above, when using tunnels, the

same parser

40, 42 may parse more than one header of the same type from the header portion. When a tunnel header (inner header) is to be processed, the tunnel bits are sent to the

next hardware parser

40, 42 together with the header portion. When the

next parser

40, 42 receives the header portion with the tunnel bit, the parser 4042 processes the header according to the tunnel, which means that the data resulting from the parsing process (e.g., offset and extracted data) is saved to a location in the buffer 16 defined in the tunnel behavior field 68.

If the subset of data 50 used by one of the flexible hardware parsers 40 does not include next header information or the header does not include next header information, parsing is stopped (and the header portion is not passed to the other hardware parser 40, 42) and further processing of the packet is passed to the packet processing engine 20 (FIG. 1).

As previously described, the resolution performed by the local hardware parser 42 is not configured by the set of resolution configuration data stored in the parser configuration registers 24. However, to enable one of local hardware resolvers 42 to pass the header portion to one of flexible hardware resolvers 40, data subset 50 includes compare data field 70 and start header field 72. Each local hardware parser 42 includes a multiplexer (not shown) that receives the header portion and the offset calculated by that local hardware parser 42 from the local hardware parser 42 and routes the header portion and offset to the next flexible hardware parser 40 via one of the connections 44. The multiplexer selects the relevant connection 44 as follows. The multiplexer retrieves the next header identification from the header processed by the local hardware parser 42. The multiplexer searches the compare data field 70 of the data subset 50 until a match is found. A match means that the multiplexer should send the header portion and the offset to the flexible hardware parser 40 associated with the data subset 50 where the match was found. The multiplexer then retrieves the protocol value found in the start field 72 of the data subset 50 in which the match was found, thereby providing an identification of one of the connections 44 (FIG. 2) to the flexible hardware parser 40 associated with the data subset 50. If the multiplexer cannot find a match with the next header identification in any of the subsets of data 50, parsing is stopped and further processing of the packet is passed to the packet processing engine 20 (FIG. 1).

Referring now to fig. 5, fig. 5 is a flow chart 100 of steps in a parsing method that includes the device 10 of fig. 1. Reference is also made to fig. 4. For clarity, the method is described with reference to flexible hardware parser 40-1. However, the method may be applied to any flexible hardware parser 40.

The flexible hardware parser 40-1 is configured to receive (block 102) an absolute offset (from the beginning of the header portion) where the

previous hardware parser

40, 42 completed parsing from the

previous hardware parser

40, 42. If the parser 40-1 is the first parser to parse the header portion, the flexible hardware parser 40-1 does not receive any offset and assumes that the offset is zero. The offset will be used in the parsing process described below. Accordingly, each of the

hardware parsers

40, 42 is configured to continuously parse the header portion according to each offset in the header portion.

The flexible hardware parser 40-1 is configured to retrieve (block 104) a header size offset from the header size offset field 52 (fig. 4), and optionally mask data from the header size mask field 54 (fig. 4). The flexible hardware parser 40-1 is configured to retrieve (block 106) a header size from a header size (relative) offset in the header. The flexible hardware parser 40-1 is configured to calculate (block 108) an offset for passing to the

next hardware parser

40, 42 responsive to the retrieved header size and the offset received in the step of block 102. The calculated offset provides the offset of the last bit in this header. Thus, the flexible hardware parser 40-1 is configured to calculate an offset in response to the header size offset field 52 (and optionally the header size mask field 54) of the parsed configuration data and the header size from the header portion and the offset received in the step of block 102. The calculated offset may be stored in the buffer 16 and/or passed to the packet processing engine 20 in addition to being passed to the

next hardware parser

40, 42.

As described above, the data subset 50 of the parsing configuration data set 48 for the flexible hardware parser 40-1 includes a data extraction offset field 64, the data extraction offset field 64 identifying an offset in a header portion from which data is to be extracted. The flexible hardware parser 40-1 is configured to retrieve (block 110) an offset from the data extraction offset field 64 in response to the data extraction offset and extract data from a header of the header portion (block 112). The extracted data may be stored in a buffer 16 and/or passed to a packet processing engine 20.

As described above, data subset 50 for flexible hardware parser 40-1 includes: a next header offset field 58 that provides a next header offset for a next header Identification (ID) in the header of the header portion; and a next protocol table 62 linking the next header ID and the next protocol. The flexible hardware parser 40-1 is coupled to retrieve (block 114) a next header offset from the data subset 50 of the flexible hardware parser 40-1 in the parser configuration registers 24 (FIG. 1). The flexible hardware parser 40-1 is coupled to retrieve (block 116) from the header portion a next header ID located at a next header offset in a header of the header portion in response to the retrieved next header offset. The flexible hardware parser 40-1 is coupled to retrieve (block 118) from the next protocol table 62 of the data subset 50 of the flexible hardware parser 40-1 in the parser configuration register 24 an identification of a next protocol to process (fig. 1) in response to the retrieved next header ID. The flexible hardware parser 40-1 is coupled to transmit (block 120) the header portion to one of the

hardware parsers

40, 42, the

hardware parser

40, 42 configured to parse a next header of the header portion according to a next protocol. The identity of the next protocol provides the identity of the connection 44 through which the flexible hardware parser 40-1 connects to the

next hardware parser

40, 42. The flexible hardware parser 40-1 is coupled to send (block 122) the offset calculated in the step of block 108 to the

next hardware parser

40, 42. The next hardware resolver 40 repeats the steps of blocks 102-122, and so on.

Referring now to fig. 6, fig. 6 is a flow chart 200 including steps in a method of operation of the device 10 of fig. 1. Reference is also made to fig. 1.

The hardware parser 18 is coupled to receive (block 202) data of a header portion of the packet. The header portion includes respective headers. In some embodiments, the controller 22 is configured to select a packet from the buffer 16 and load the packet into the hardware parser 18 for parsing by the hardware parser 18.

The controller 22 is configured to load (block 204) a default resolver configuration set into the resolver configuration register 24 from the selection 32 of resolver configuration data sets cached in the cache memory 26. The parser configuration registers 24 are configured to store a default parse configuration data set.

One of the

hardware parsers

40, 42 may be defined as an initial parser to receive a header portion for parsing. The initial parser may be fixed or may be configured according to data stored in the parser configuration registers 24.

At least one of the

hardware parsers

40, 42 is configured to parse (block 206) at least one header of the header portion in response to a default parsing configuration data set, thereby generating first parsed data. The default parsing configuration data set may be populated such that one or more flexible hardware parsers 40 and/or one or more local hardware parsers 42 parse at least a portion of the header portion, e.g., one of the local hardware parsers 42 (e.g., MAC hardware parser) parses the MAC header. For example, the default parsing configuration data set may include data such that there is no next header after the MAC parser, resulting in a parsing completion after the MAC parser completes the parsing.

The packet processing engine 20 is coupled to the hardware parser 18. The packet processing engine 20 is configured to select (block 208) a parsed configuration data set from the selection 32 of parsed configuration data sets in response to the first parsed data, for example, using the match and action table 28. The packet processing engine 20 is configured to cause the selected resolver configuration data set to be loaded from the cache memory 26 into the resolver configuration registers 24 (block 210). The packet processing engine 20 typically sends a command to the controller 22 configured to load the selected set of parser configurations from the cache memory 26 into the parser configuration registers 24.

Typically, under the control of the controller 22, the

hardware parser

40, 42 is configured to parse (block 212) the same header portions again in accordance with the selected parsing configuration data. The

hardware parser

40, 42 is configured to parse the respective headers of the header portions in response to the selected parsing configuration data set, thereby generating second parsed data. It should be noted that even though one of the

hardware parsers

40, 42 may parse two or more headers, e.g., two MAC headers, when using a tunnel, each header is parsed by one of the

hardware parsers

40, 42.

The packet processing engine 20 is configured to process (block 214) the packet in response to the second parsed data, for example, using the match and action table 28. The processing may include any suitable processing, including the examples provided above with reference to fig. 1 and below. The packet processing engine 20 may be configured to forward (block 216) the packet to a virtual machine running on the server 34 via the communication bus interface 30 or to a network node 36 in the packet data network 14 via an egress port of the network interface 12 in response to the second parsed data. The packet processing engine 20 is configured to change the data in the header portion in response to the second parsed data (block 218).

For example, the resolution functionality of network device 10 may be shared between different VNFs each having different resolution requirements. In a virtualized environment where there are multiple VNFs (e.g., network interface cards) running on the network device 10, each VNF may have its own resolution scheme requirements (e.g., a proprietary header that needs to be resolved for a particular VNF). One example of a VNF is the User Plane Function (UPF), which must parse the General Packet Radio Service (GPRS) tunneling protocol (GTP) header. Assuming the VNF is running on a VXLAN virtualization environment, the default parser configuration will parse the VXLAN header of the packet. The rules in the match and action table 28 will identify the correct VNF based on the initial parsing of the packet's outer header. After identifying the VNF, the packet processing engine 20 strips the outer header from the header portion of the packet and instructs the controller 22 to load the parsing configuration set for that VNF into the parser configuration register 24 to parse the GTP header. Another VNF using the same network device 10 may include a firewall that performs IPSEC. In this case, identifying the VNF from the packet header may result in a set of parsing configurations for the VNF being loaded into the parser configuration registers 24 to support IPSEC parsing.

Thus, the

hardware parser

40, 42 is configured to parse header portions of respective Virtual Network Functions (VNFs) having respective header parsing schemes in response to respective ones of the selected 32 ones of the parsed configuration data sets. The packet processing engine 20 may be configured to identify a first VNF of the VNFs from a network address included in the first resolution data. The step of block 208 may include the packet processing engine 20 being configured to select the selected parsing configuration data set from the selection of parsing configuration data sets 32 in response to the first parsing data being identified as associated with the first VNF. The step of block 212 may comprise a

hardware parser

40, 42 configured to parse the respective headers according to a header parsing scheme of the first VNF in response to the selected parsing configuration data set of the first VNF, thereby generating second parsed data. The step of block 214 may include the packet processing engine 20 configured to forward the packet to the virtual machine of the first VNF, for example, in response to the second parsed data.

According to another example, the number of hardware resolvers 18 limits the number of protocols that may be supported without selectively loading different ones of the choices 32 of the resolved configuration data set into the resolver configuration registers 24. For example, the default parsing configuration data set is not configured to support VXLAN headers. After the initial parsing phase reaches the UDP header, the UDP destination port will be extracted and the parsing will stop. The packet processing engine 20 uses the matching table and action table 28 to look up the UDP destination port. If the UDP destination port indicates VXLAN, the controller 22 loads a parsing configuration data set supporting VXLAN parsing into the parser configuration register 24 and instructs the flexible hardware parser 40 to re-parse the header portion accordingly.

Various features of the invention which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination.

The embodiments described above are cited by way of example, and the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.

Claims

1. A network device, comprising:

a hardware parser coupled to receive data of a header portion of a packet, the header portion including respective headers;

a parser configuration register configured to store a default parsing configuration data set, wherein at least one of the hardware parsers is configured to parse at least one of the headers in response to the default parsing configuration data set, producing first parsed data;

a packet processing engine coupled with the hardware parser and configured to:

in response to the first parsing data identified as being associated with a given one of the VMs, selecting a Virtual Machine (VM) parsing configuration data set from a selection of VM parsing configuration data sets of the respective VM having a respective header parsing scheme;

causing the selected VM parse configuration data set to be loaded into the parser configuration register, and wherein some of the hardware parsers are configured to parse respective ones of the headers according to a respective one of the header parsing schemes of the given VM in response to the selected VM parse configuration data set, generating second parsed data; and

processing the packet in response to the second parsed data.

2. The apparatus of claim 1, further comprising an interface configured as an egress port, wherein the packet processing engine is configured to forward the packet to a network node in a packet data network via the egress port in response to the second parsed data.

3. The device of claim 1, wherein the packet processing engine is configured to change data in the header portion in response to the second parsed data.

4. The apparatus of claim 1, further comprising: a cache memory configured to cache a selection of a VM parse configuration data set including the selected VM parse configuration data set, the packet processing engine configured to cause the selected VM parse configuration data set to be loaded from the cache memory into the parser configuration register.

5. The apparatus of claim 1, wherein,

the hardware parser is configured to parse header portions of respective Virtual Network Functions (VNFs) having respective header parsing schemes in response to the selected respective VM parse configuration data sets of VM parse configuration data sets;

the packet processing engine is configured to select a selected VM parse configuration data set from the selection of the VM parse configuration data sets in response to the first parse data being identified as associated with one of the VNFs;

some of the hardware parsers are configured to parse respective ones of the headers according to one of the header parsing schemes of the one VNF in response to the selected VM parsing configuration dataset; and is

The packet processing engine is configured to forward the packet in response to the second parsed data.

6. The apparatus of claim 5, wherein the respective VNFs comprise at least one virtual machine.

7. The apparatus of claim 6, wherein the packet processing engine is configured to forward the packet to a virtual machine in response to the second parsed data.

8. The apparatus of claim 6, wherein the packet processing engine is configured to identify the one VNF from a network address included in the first resolution data.

9. The apparatus of claim 1, wherein respective hardware parsers are configured to successively parse the header portion according to respective offsets in the header portion, some of the hardware parsers configured to calculate the respective offsets in response to the selected VM parse configuration data and the header portion.

10. The apparatus of claim 9, wherein the selected VM parses a configuration data set comprising, for each of the hardware parsers: a next header offset of a next header Identification (ID) in the header portion; and a next protocol table linking a next header ID with a next protocol, wherein a first one of the hardware resolvers is coupled to:

retrieving, in the parser configuration register, a next header offset for the first hardware parser from the selected VM parse configuration dataset;

retrieving the next header ID from the header portion in response to the retrieved next header offset, the header ID being located at the next header offset in the header portion;

in response to the retrieved next header ID, parsing a configuration dataset from the selected VM in the parser configuration register, retrieving an identification of a next protocol to process from a next protocol table for the first hardware parser; and

transmitting the header portion to a second one of the hardware parsers configured to parse the header portion according to the next protocol.

11. The apparatus of claim 9, wherein the selected VM parsing the configuration data set comprises: for each of the hardware resolvers, at least one data extraction offset in a header portion for which data is to be extracted, a first one of the hardware resolvers configured to extract data from the header portion in response to the at least one data extraction offset of the first hardware resolver in the selected VM parse configuration dataset.

12. A networking method, comprising:

receiving data of a header portion of a packet, the header portion including respective headers;

storing a default parsing configuration data set in a parser configuration register;

parsing at least one of the headers in response to the default parsing configuration data set, resulting in first parsed data;

in response to the first parsing data identified as being associated with a given one of the VMs, selecting a VM parsing configuration data set from a selection of VM parsing configuration data sets of the respective VM having a respective header parsing scheme;

causing the selected VM parse configuration data set to be loaded into the parser configuration register;

parsing, in response to the selected VM parsing configuration data set, each of the headers according to a respective one of the given VM's header parsing schemes, producing second parsed data; and

processing the packet in response to the second parsed data.

13. The method of claim 12, further comprising forwarding the packet to a network node in a packet data network via an egress port in response to the second parsed data.

14. The method of claim 12, further comprising changing data in the header portion in response to the second parsed data.

15. The method of claim 12, further comprising: caching a selection of a VM parse configuration data set including the selected VM parse configuration data set in a cache memory; and causing the selected VM parse configuration data set to be loaded from the cache memory into the parser configuration register.

16. The method of claim 12, further comprising:

parsing header portions of respective Virtual Network Functions (VNFs) having respective header parsing schemes in response to the selected respective VM parse configuration data sets of VM parse configuration data sets;

selecting a selected VM parse configuration data set from the selection of the VM parse configuration data sets in response to the first parse data being identified as associated with one of the VNFs;

parsing, in response to the selected VM parsing the configuration data set, respective ones of the headers according to one of the header parsing schemes of the one VNF; and

forwarding the packet in response to the second parsed data.

17. The method of claim 16, wherein the respective VNFs comprise at least one virtual machine.

18. The method of claim 17, further comprising forwarding the packet to a virtual machine in response to the second parsed data.

19. The method of claim 17, further comprising identifying the one VNF from a network address included in the first resolution data.

20. The method of claim 12, further comprising:

successively parsing the header portion according to respective offsets in the header portion; and

calculating the respective offsets in response to the selected VM parse configuration data and the header portion.

21. The method of claim 20, wherein the selected VM parsing the configuration data set comprises: a next header offset of a next header Identification (ID) in the header portion; and a next protocol table linking the next header ID with the next protocol, the method further comprising:

retrieving the next header offset from the selected VM parse configuration dataset;

parsing a configuration dataset from the selected VM responsive to the retrieved next header ID, retrieving an identification of a next protocol to process from the next protocol table; and

parsing the header portion according to the next protocol.

22. The method of claim 20, wherein the selected VM parse configuration data set includes at least one data extraction offset in a header portion for which data is to be extracted, the method further comprising extracting data from the header portion in response to the at least one data extraction offset of the first hardware parser in the selected VM parse configuration data set.