CN112136108A - Header analysis device and method - Google Patents
Header analysis device and method Download PDFInfo
- Publication number
- CN112136108A CN112136108A CN201880093593.7A CN201880093593A CN112136108A CN 112136108 A CN112136108 A CN 112136108A CN 201880093593 A CN201880093593 A CN 201880093593A CN 112136108 A CN112136108 A CN 112136108A
- Authority
- CN
- China
- Prior art keywords
- layer header
- protocol type
- current layer
- header
- processor
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 238000004458 analytical method Methods 0.000 title description 36
- 238000012545 processing Methods 0.000 claims abstract description 14
- 238000000605 extraction Methods 0.000 claims description 21
- 238000005538 encapsulation Methods 0.000 description 12
- 238000013461 design Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 11
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 108700026140 MAC combination Proteins 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 101100497196 Arabidopsis thaliana CPN60B1 gene Proteins 0.000 description 1
- 101100317049 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) VLD1 gene Proteins 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
Abstract
A header parsing apparatus and method are provided to improve scalability of a parsing scheme. The apparatus comprises a first processor and a second processor; the first processor is used for analyzing the current layer header under the condition that the protocol type corresponding to the current layer header is the first protocol type; the head of the message to be analyzed comprises a multilayer header; the second processor is used for analyzing the current layer header under the condition that the protocol type corresponding to the current layer header is the second protocol type; the first protocol type is an extension protocol type, and the second protocol type is an inherent protocol type; the first processor is a processor having programmable processing capabilities and the second processor is a processor having no programmable processing capabilities.
Description
The present application relates to the field of communications technologies, and in particular, to a header parsing apparatus and method.
After receiving the message, the network device needs to analyze the header, so as to determine how to process the message according to the result of the header analysis. Generally, when the network device performs header parsing, the network device parses the header layer by layer in a hardware parsing manner: the network device performs content identification of headers of different layers from a bottom layer to a high layer, wherein the operation performed on each layer of headers is similar. That is, when each layer header is parsed, a protocol field of a fixed position can be extracted, and the protocol type of the next layer header can be determined from the protocol field. In addition, the network device can also perform corresponding extraction and check operations on other fields except the protocol field.
For example, for the header shown in fig. 1, when the network device performs parsing, first, according to the configuration of a message to be parsed, it determines that a protocol Type corresponding to the first layer header is a Media Access Control (MAC), and then determines a position of a Type field in the first layer header; after the Type field in the first layer header is analyzed, if the Type field is found to be 0x88A8, it can be determined that the protocol Type corresponding to the second layer header is a service virtual local area network (S-VLAN); meanwhile, corresponding extraction and checking can be performed for other fields except for the Type field in the first layer header. When the second-layer header is analyzed, determining that the protocol Type corresponding to the second-layer header is S-VLAN through the Type field 0x88A8 in the first-layer header, and further determining the position of the Type field in the second-layer header; the Type field is analyzed, so that the protocol Type corresponding to the third header can be obtained, and other fields except the Type field can be correspondingly extracted and checked; thereafter, each layer of headers is parsed in a similar manner until the fifth layer of headers, i.e., User Datagram Protocol (UDP) headers, are parsed. Since the fifth layer header is the last layer header, the relevant fields are extracted and checked accordingly, and the Type field does not need to be extracted any more.
In the hardware parsing manner described above, a chip for performing a parsing operation can only be used for header parsing of a known protocol once the chip is manufactured. If a new protocol type appears along with the development of the technology, the analysis of the new protocol type is difficult to support by adopting a hardware analysis mode.
Therefore, a header parsing method is needed, so that when the protocol type corresponding to the multi-layer header includes the extension protocol type, the header can still be parsed, and the extensibility is improved.
Disclosure of Invention
The embodiment of the application provides a header analysis device and a header analysis method, which are used for improving the expandability of an analysis scheme.
In a first aspect, an embodiment of the present application provides a header parsing apparatus. The method comprises the following steps: the first processor is used for analyzing the current layer header under the condition that the protocol type corresponding to the current layer header is the first protocol type; the head of the message to be analyzed comprises a multilayer header; and the second processor is used for analyzing the current layer header under the condition that the protocol type corresponding to the current layer header is the second protocol type.
The first protocol type is an extension protocol type, and the second protocol type is an inherent protocol type; the first processor is a processor having programmable processing capabilities and the second processor is a processor having no programmable processing capabilities.
The protocol type corresponding to the current layer header includes but is not limited to: a medium access control, MAC; a service virtual local area network (S-VLAN); a user virtual local area network C-VLAN; a virtual extended local area network VxLAN; internet protocol version four IPv 4; internet protocol version six IPv 6; a transmission control protocol TCP; user datagram protocol UDP; internet control message protocol ICMP; the dynamic host configuration protocol DHCP.
By adopting the scheme, one of the first processor and the second processor can be selected to analyze the current layer header according to the protocol type corresponding to the current layer header. And the second processor analyzes the current layer header in a hardware analysis mode. The hardware analysis mode is used for analyzing the header of the inherent protocol type, and the programmable analysis mode is used for analyzing the header of the extended protocol type, so that the scheme can be used for analyzing the header of the inherent protocol type and the header of the extended protocol type. After the chip is manufactured, if the header of the extended protocol type needs to be analyzed, the header of the extended protocol type can be analyzed only by correspondingly configuring the reserved programmable capacity, so that the expandability of the analysis scheme is improved.
Furthermore, the header parsing apparatus provided in the first aspect may further include: a first data selector for selecting and outputting a type field in the current layer header output by the first processor according to a first selection signal, or selecting and outputting a type field in the current layer header output by the second processor according to the first selection signal; the type field in the current layer header is used for indicating the protocol type corresponding to the next layer header of the current layer header, and the first selection signal is used for indicating the processor for analyzing the current layer header.
By adopting the scheme, the type field can be extracted after the current layer header is analyzed, and the type field is used for analyzing the next layer header.
Furthermore, in the header parsing apparatus provided in the first aspect, there may be a case that the current layer header is the last layer header, and then the first processor or the second processor may be further configured to: after the current layer header is analyzed, the current layer header is determined to be the last layer header in the header of the message to be analyzed.
By adopting the scheme, the first processor or the second processor can judge that the current layer header is the last layer header, and further judge that the next layer header does not need to be analyzed. The type field in the current layer header may not be extracted at this time.
In a possible design, if the current layer header is the first layer header in the header of the message to be analyzed, the protocol type corresponding to the current layer header is determined according to the configuration information of the message to be analyzed; if the current layer header is not the first layer header in the header of the message to be analyzed, determining the protocol type corresponding to the current layer header according to the type field in the previous layer header of the current layer header; the type field in the upper layer header of the current layer header is used for indicating the protocol type corresponding to the current layer header.
By adopting the scheme, two specific modes for determining the protocol type corresponding to the current layer header are provided.
In one possible design, the first processor may be configured with a register having a protocol type table stored therein, and then the first processor is further configured to: judging whether the protocol type corresponding to the header of the current layer is in the protocol types contained in the protocol type table; if the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is a first protocol type; and if the protocol type corresponding to the current layer header is not in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is not the first protocol type.
In addition, the header parsing apparatus provided in the first aspect may further include a second data selector and a field extraction module. The second data selector is used for selecting and outputting other fields output by the first processor and in the current layer header according to a second selection signal, or selecting and outputting other fields output by the second processor according to the second selection signal; this other field may be used for check checking; the second selection signal is used for indicating a processor for analyzing the header of the current layer; and the field extraction module is used for extracting other fields output by the second data selector.
By adopting the scheme, other fields in the header of the current layer can be extracted, so that the other fields are checked.
In a second aspect, an embodiment of the present application further provides a header parsing method, where the method includes the following steps: judging whether a protocol type corresponding to a current layer header in a header of a message to be analyzed is a first protocol type; analyzing the current layer header through a first processor under the condition that the protocol type corresponding to the current layer header is a first protocol type; the head of the message to be analyzed comprises a multilayer header; and under the condition that the protocol type corresponding to the current layer header is a second protocol type, the current layer header is analyzed through the second processor.
The first protocol type is an extension protocol type, and the second protocol type is an inherent protocol type; the first processor is a processor having programmable processing capabilities and the second processor is a processor having no programmable processing capabilities.
In one possible design, the method further includes: selecting and outputting a type field in a current layer header output by a first processor according to a first selection signal or selecting and outputting a type field in a current layer header output by a second processor according to the first selection signal; the type field in the header of the current layer is used for indicating the protocol type corresponding to the header of the next layer of the header of the current layer; the first selection signal is used to indicate a processor that parses the current layer header.
In one possible design, after parsing the current layer header, the method further includes: and determining that the current layer header is the last layer header in the header of the message to be analyzed.
In a possible design, the current layer header is the first layer header in the header of the message to be analyzed, and the protocol type corresponding to the current layer header is determined according to the configuration information of the message to be analyzed; if the current layer header is not the first layer header in the header of the message to be analyzed, determining the protocol type corresponding to the current layer header according to the type field in the previous layer header of the current layer header; the type field in the upper layer header of the current layer header is used for indicating the protocol type corresponding to the current layer header.
In a possible design, a register is configured in the first processor, a protocol type table is stored in the register, and whether a protocol type corresponding to a current layer header in a header of a message to be analyzed is a first protocol type is determined, including: judging whether the protocol type corresponding to the header of the current layer is in the protocol types contained in the protocol type table; if the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is a first protocol type; and if the protocol type corresponding to the current layer header is not in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is not the first protocol type.
In one possible design, the method further includes: extracting other fields in the current layer header output by the first processor or the second processor; the other fields are used for check checking.
Fig. 1 is a schematic diagram of a header encapsulation structure provided in the prior art;
fig. 2 is a schematic structural diagram of a hardware parsing unit according to an embodiment of the present disclosure;
fig. 3 is a schematic diagram of a packet encapsulation structure according to an embodiment of the present application;
fig. 4 is a schematic diagram of another packet encapsulation structure provided in the embodiment of the present application;
fig. 5 is a schematic structural diagram of a first header parsing apparatus according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a protocol type table according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of a second header parsing apparatus according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of a third header parsing apparatus according to an embodiment of the present application;
fig. 9 is a schematic flowchart of a header parsing method according to an embodiment of the present application;
fig. 10 is a schematic flowchart of another header parsing method according to an embodiment of the present application;
fig. 11 is a schematic diagram of a first header encapsulation structure according to an embodiment of the present application;
fig. 12 is a schematic diagram of a second header encapsulation structure according to an embodiment of the present application.
As described in the background, network devices typically employ hardware parsing when parsing headers. The hardware analysis mode sequentially identifies the header content from the bottom layer to the high layer through a header identification module. The operation when parsing each layer header is similar.
Specifically, each layer header may be parsed using the hardware parsing unit shown in fig. 2.
The hardware parsing unit shown in fig. 2 includes a Header Identification module (Header Identification), a Field Extraction module (Field Extraction), and a Field Buffer module (Field Buffer). The header identification module is used for identifying a header, and acquiring the position of a Type field for indicating the protocol Type of a next layer header by identifying header data; the field extraction module extracts the relevant fields according to the identification result of the head identification module; the field cache module is used for temporarily storing the contents of each field extracted by the field extraction module. After the header is identified and extracted by the parsing unit shown in fig. 2, the extracted contents of each field can be transmitted to a matching Engine (Match Engine). Whether the information in the header is wrong or not can be analyzed through the matching engine, and the protocol type corresponding to the header of the next layer of the header of the current layer can be analyzed.
However, only the header of the fixed protocol type can be parsed using the hardware parsing unit shown in fig. 2. If the protocol type corresponding to the header is the extension protocol type, the hardware parsing unit shown in fig. 2 cannot be used for parsing.
Based on the above problems, embodiments of the present application provide a header parsing apparatus and method, so as to implement parsing of a header when a protocol type corresponding to a multi-layer header includes an extension protocol type, thereby improving scalability of a parsing scheme and improving parsing efficiency of the header. The method and the device are based on the same inventive concept, and because the principles of solving the problems of the method and the device are similar, the implementation of the device and the method can be mutually referred, and repeated parts are not repeated.
In the present application, the plural number means two or more. In addition, it is to be understood that the terms first, second, etc. in the description of the present application are used for distinguishing between the descriptions and not necessarily for describing a sequential or chronological order.
The following describes a message encapsulation structure applicable to the embodiment of the present application.
The message packaging structure is suitable for the message packaging structure containing the multi-layer header. Each layer of header in the multi-layer header may correspond to a known protocol type, or may correspond to an extended protocol type. Of course, a part of the multi-layer header may correspond to a known protocol type, and another part of the header may correspond to an extended protocol type.
For example, the embodiment of the present application may be applied to the message encapsulation structure shown in fig. 3. The message encapsulation structure shown in fig. 3 contains a three-layer header. The first layer header supports a MAC protocol type and an extended protocol type (TBD 1); the layer two header supports fifty known protocol types (e.g., 1588, IPv4, IPv6, etc.) and an extended protocol type (TBD 1); the third layer header supports fifty known protocol types (e.g., TCP, UDP, etc.) and two extended protocol types (TBD1 and TBD 2).
For example, the embodiment of the present application may be applied to the message encapsulation structure shown in fig. 4. The message encapsulation structure shown in fig. 4 contains a four-layer header. The first layer header supports a MAC protocol type; the layer two header supports fifty known protocol types (e.g., 1588, IPv4, IPv6, etc.) and an extended protocol type (TBD 1); the third layer header supports fifty known protocol types (e.g., TCP, UDP, etc.) and two extended protocol types (TBD1 and TBD 2); the fourth layer header supports sixty-four known protocol types (e.g., DHCP, VxLAN, etc.) and an extended protocol type (TBD 1).
In order to make the objects, technical solutions and advantages of the present application more clear, a header parsing scheme provided by an embodiment of the present application is specifically described below with reference to the accompanying drawings.
Fig. 5 is a schematic structural diagram of a header parsing apparatus according to an embodiment of the present application. The header of the message to be analyzed comprises a plurality of layers of headers which are in one-to-one correspondence with a plurality of protocol types. In fig. 5, the header parsing apparatus 500 includes a first processor 501 and a second processor 502.
A first processor 501, configured to parse a current layer header if a protocol type corresponding to the current layer header is a first protocol type; the header of the message to be parsed includes a multi-layer header.
A second processor 502, configured to parse the current layer header if the protocol type corresponding to the current layer header is the second protocol type.
The first protocol type is an extension protocol type, and the second protocol type is an inherent protocol type; the first processor 501 is a processor having programmable processing capability and the second processor is a processor having no programmable processing capability.
In particular, the first processor 501 may also be referred to as a programmable processor, and the second processor 502 may also be referred to as a hardware processor; the second protocol type may be understood as a protocol type that appears before the header parsing apparatus 500 is manufactured, and headers of the protocol types may be parsed by the second processor 502 in a hardware parsing manner; the first protocol type may be understood as the protocol types that appear after the header parsing apparatus 500 is manufactured, and the headers of these protocol types may be parsed by the first processor 501 in a programmable parsing manner.
In this embodiment of the present application, the protocol type corresponding to the current layer header includes, but is not limited to, a Medium Access Control (MAC); a service virtual local area network (S-VLAN); a customer virtual local area network (C-VLAN); a virtual extensible local area network (VxLAN); internet protocol version four (IPv 4); internet protocol version six (IPv 6); transmission Control Protocol (TCP); user Datagram Protocol (UDP); internet Control Message Protocol (ICMP); dynamic Host Configuration Protocol (DHCP).
It should be noted that the above protocol type corresponding to the current layer header is only an example, and in practical application, the protocol type corresponding to the current layer header is not limited to the above example.
For a specific packet format, the current layer header may be the first layer header or a layer header other than the first layer header. For example, for the encapsulation structure shown in FIG. 1, the first layer header is a MAC header and the other headers include S-VLAN headers, C-VLAN headers, and the like.
Specifically, the manner of determining the protocol type corresponding to the current layer header differs for the first layer header and the other layer headers.
For the first layer header, the protocol type corresponding to the current layer header may be determined according to the configuration information of the packet to be analyzed. For example, the protocol type corresponding to the first layer header may be determined by the port configuration information of the packet to be parsed, that is, the protocol type corresponding to the first layer header may be determined by the port that receives the packet to be parsed. Illustratively, the protocol type corresponding to the first layer header may be MAC or Fibre Channel (FC).
For other layer headers, the protocol type corresponding to the current layer header may be determined according to a type field in a previous layer header of the current layer header, where the type field in the previous layer header of the current layer header is used to indicate the protocol type corresponding to the current layer header. That is, by parsing the previous layer header, the type field in the previous layer header can be obtained, and the protocol type corresponding to the current layer header is known.
In practical implementation, the Type field may also be referred to as a Type field.
That is, if the current layer header is the first layer header in the header of the message to be analyzed, the protocol type corresponding to the current layer header is determined according to the configuration information of the message to be analyzed; if the current layer header is not the first layer header in the header of the message to be analyzed, determining the protocol type corresponding to the current layer header according to the type field in the previous layer header of the current layer header; the type field in the upper layer header of the current layer header is used for indicating the protocol type corresponding to the current layer header.
In a specific implementation, the operation of determining the protocol type corresponding to the current layer header may be performed by the first processor 501, the second processor 502, or a separate module. In the embodiment of the present application, an execution subject for executing the operation is not particularly limited.
In this embodiment of the present application, the first processor 501 may determine whether a protocol type corresponding to a current layer header is a first protocol type, if so, the first processor 501 parses the current layer header, if not, the second processor 502 performs matching of the protocol type, and if matching is successful, the second processor 502 parses the current layer header; if the matching fails, the parsing of the current layer header will report an error. The way for the second processor 502 to perform the protocol type matching is the prior art, and is not described herein again. The following describes a specific manner of determining whether the protocol type corresponding to the current layer header is the first protocol type by the first processor 502.
In a specific implementation, the first processor 501 may be configured with a register, and the register may store a protocol type table, so that when determining whether a protocol type corresponding to a current layer header in a header of a to-be-analyzed packet is a first protocol type, the first processor 501 may specifically implement the following method: judging whether the protocol type corresponding to the header of the current layer is in the protocol types contained in the protocol type table; if the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is a first protocol type; and if the protocol type corresponding to the current layer header is not in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is not the first protocol type.
The protocol type table is used to indicate a protocol type corresponding to a header that can be parsed by the first processor 501. That is, in order to determine which headers of the protocol types can be parsed by the first processor 501 in a programmable parsing manner, in the embodiment of the present application, a protocol type table is maintained, and the protocol type table may be implemented by using a configuration register (i.e., the protocol type table is stored in the configuration register). If the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table (i.e. the protocol type corresponding to the current layer header is consistent with the protocol type of a certain entry in the protocol type table), the current layer header is parsed by the first processor 501; if the protocol type corresponding to the current layer header is not in the protocol types contained in the protocol type table (i.e. the protocol type corresponding to the current layer header is not consistent with the protocol type of any entry in the protocol type table), the current layer header is parsed by the second processor 502.
Of course, in this embodiment of the present application, the protocol type table may further include other configuration information of the current layer header. For example, the length of the current layer header, the offset position and length of the type field in the current layer header, and the offset position and length of the other fields in the current layer header other than the type field. The type field in the current layer header is used for indicating the protocol type corresponding to the next layer header of the current layer header; other fields may be used to perform the corresponding check checks.
Illustratively, the protocol type table may also be referred to as a register table. In one possible example, the configuration information contained in each entry of the register table may be as shown in FIG. 6. The Type field indicates the Type of the protocol indicated by the entry, that is, the value of the Type field extracted from the upper-layer header is equal to the value of the Type field in the register table, which indicates that a new protocol is hit, and the first processor 501 needs to parse the current-layer header. HDR LEN denotes the length of the current layer header in Byte. TYPE _ OFS indicates an offset position of a TYPE field indicating a protocol TYPE corresponding to a next layer header in the current layer header in Byte units. TYPE _ LEN indicates the length of a TYPE field in the current layer header for indicating the protocol TYPE corresponding to the next layer header, in Byte units. F _ OFSn/F _ LENn (n is 0-3) represents the offset position and length of other fields except the Type field in the header of the current layer, and the offset position and length are all in bit. 4 other fields are defined in the entry shown in fig. 6. When the method is used, the TYPE _ VLD/F _ VLDN can be set to be 1 or clear 0 according to requirements, and whether the corresponding field needs to be extracted and identified or not is indicated. For example, when F _ VLD1 is 1, a field indicating offset setting of F _ OFS1 and length of F _ LEN1 needs to be extracted and identified.
In addition, in this embodiment, the header parsing apparatus 500 may further include a first data selector. After the current layer header is parsed by the first processor 501 or the second processor 502, the first data selector may select to output a type field in the current layer header output by the first processor 501 according to a first selection signal, or select to output a type field in the current layer header output by the second processor 502 according to a first selection signal. The type field in the current layer header is used for indicating the protocol type corresponding to the next layer header of the current layer header, and the first selection signal is used for indicating the processor for analyzing the current layer header.
The first selection signal may be output to the first data selector by the first processor 501 after determining whether a protocol type corresponding to a current layer header in a header of the message to be parsed is a first protocol type; specifically, after determining that the protocol type corresponding to the current layer header is the first protocol type, the first processor 501 may determine that the current layer header is parsed by itself, and at this time, the first processor 501 may output a first selection signal to the first data selector to indicate that the processor parsing the current layer header is the first processor 501.
Of course, the first selection signal may also be output to the first data selector by the second processor 502. Specifically, the second processor 502 may determine that the current layer header is parsed by itself if the protocol type corresponding to the current layer header is the second protocol type, at this time, the second processor 502 may output a first selection signal to the first data selector to indicate that the processor parsing the current layer header is the second processor 502.
The first selection signal may be used to indicate whether the first processor 501 or the second processor 502 parses the current layer header. If the first processor 501 analyzes the current layer header, the first data selector selects and outputs the type field in the current layer header output by the first processor 501 according to the first selection signal; if the second processor 502 parses the current layer header, the first data selector selects and outputs the type field in the current layer header output by the second processor 502 according to the first selection signal.
For example, if the current layer header is the MAC header in fig. 1, after the current layer header is parsed, the Type field of the current layer header output by the first data selector is a Type field in the MAC header, where the Type field is used to indicate a protocol Type corresponding to a next layer header (i.e., an S-VLAN header) of the current layer header (i.e., the MAC header).
Of course, if the current layer header is the last layer header, after the first processor 501 or the second processor 502 parses the current layer header, the first processor 501 or the second processor 502 may determine that the current layer header is the last layer header in the header of the message to be parsed according to the parsing result.
In addition, after the current layer header is analyzed, not only the type field in the current layer header can be extracted, but also other fields except the type field in the current layer header can be extracted; this other field may be used for check checking.
In a specific implementation, the header parsing apparatus 500 may further include a second data selector and a field extraction module, where the second data selector may be configured to select and output other fields in the current layer header output by the first processor 501 according to a second selection signal, or select and output other fields in the current layer header output by the second processor 502 according to the second selection signal; the other field is used for checking and checking; the second selection signal is used for indicating a processor for analyzing the header of the current layer; the field extraction module may be operable to extract other fields of the second data selector output. The second selection signal has a similar function to the first selection signal, and is not described herein again.
That is, the second selection signal may be used to indicate whether the first processor 501 or the second processor 502 parses the current layer header. If the first processor 501 analyzes the current layer header, the second data selector selects and outputs other fields in the current layer header output by the first processor 501 according to the second selection signal; if the second processor 502 is analyzing the current layer header, the second data selector selects and outputs other fields in the current layer header output by the second processor 502 according to the second selection signal.
After the field extraction module outputs other fields, other fields may be checked by other devices (e.g., a matching engine).
The check checks on other fields can be divided into two categories: the first is correctness checking of the protocol fields. The method comprises the steps that the meaning and assignment of certain fields in a protocol type corresponding to a current layer header are required, and the legality of the current layer header is approved only if the meaning and assignment of the fields meet the requirements. For example, IPv4 requires that the version field must be 4, and if the protocol type corresponding to the current layer header is IPv4, the version field needs to be extracted and checked. If the version field value is 4, the check is passed; if the version field assignment is not 4, an error is reported. The second is flexibly configurable field value checking based on user requirements. The user may have special requirements on the assignment of certain fields in a particular scenario, and the check may only be passed if the field meets the user requirements. For example, a user may specify that a common flash memory interface (CFI) field in an S-VLAN is consistent with a CFI field configured by the user, and if a protocol type corresponding to a current layer header is the S-VLAN, the CFI field needs to be extracted and checked. If the assignment of the CFI field is consistent with the self configuration, the check is passed; if the CFI field assignment does not match the configuration itself, an error is reported.
It should be noted that, in the embodiment of the present application, the check of the other fields is an optional operation. That is, the protocol can specify that other fields need to be checked, and can also specify that other fields are not to be checked; alternatively, the user configuration may indicate that other fields are checked or may indicate that other fields are not checked.
In conjunction with the above description, when the header parsing apparatus 500 includes the first processor 501, the second processor 502, the first data selector, the second data selector, and the field extraction module, the header parsing apparatus 500 may be as shown in fig. 7.
In addition, in the embodiment of the present application, after the current-layer header is parsed, the current-layer header may be deleted from the header of the message to be parsed and then transferred to the next layer for parsing. However, since the type field in the current layer header needs to be used for determining the protocol type when the next layer parses, the type field in the current layer header should also be passed to the next layer. That is, after the field extraction module extracts the type field in the current layer header, the part of the header of the message to be parsed after the current layer header is deleted and the type field in the current layer header can be output to the next layer for parsing the next layer header of the current layer header.
For example, if the current layer header is the MAC header in fig. 1, after the current layer header is parsed, the Type field in the MAC header and the S-VLAN header, the C-VLAN header, the IPv4 header, and the UDP header following the MAC header may be passed to the next layer for parsing.
By adopting the header parsing method provided by the embodiment of the present application, one of the first processor 501 and the second processor 502 may be selected to parse the current layer header according to the protocol type corresponding to the current layer header. The programmable analysis mode is adopted when the first processor 501 analyzes the current layer header, and the hardware analysis mode is adopted when the second processor 502 analyzes the current layer header. Because the hardware parsing mode is used for parsing the header of the inherent protocol type and the programmable parsing mode is used for parsing the header of the extended protocol type, by adopting the scheme provided by the embodiment of the application, the header of the inherent protocol type can be parsed, and the header of the extended protocol type can be parsed. After the chip is manufactured, if the header of the extended protocol type needs to be analyzed, the header of the extended protocol type can be analyzed only by correspondingly configuring the reserved programmable capacity, so that the expandability of the analysis scheme is improved.
In addition, by adopting the scheme provided by the embodiment of the application, the header of the protocol type which can be determined in the design stage can be analyzed in a hardware analysis mode, and meanwhile, for the extension protocol type, the extension protocol type can be configured through the protocol type table only by reserving certain programmable capacity, so that the header of the extension protocol type can be analyzed in a programmable mode, and the user configuration is simple. Meanwhile, when judging whether a hardware analysis mode or a programmable analysis mode is adopted (namely judging which processor is adopted to analyze the current layer header), only whether the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table is determined, so that by adopting the scheme provided by the embodiment of the application, when judging which processor is adopted to analyze the current layer header, the number of times of searching and matching is less, the time delay of header analysis can be reduced, and the analysis efficiency can be improved. Meanwhile, the realization area of the chip can be saved, and the design complexity is reduced.
In this embodiment, the header of the message to be parsed includes multiple layers of headers corresponding to multiple protocol types, and the parsing of each layer of headers can be performed by the header parsing apparatus 500. That is, when parsing the header of the entire message to be parsed, the parsing may be performed by a plurality of header parsing apparatuses 500 which are cascaded, each header parsing apparatus 500 being used for parsing one layer of header. Specifically, the parsing of each layer header may be performed by one of the first processor 501 or the second processor 502. The first processor 501 may store a protocol type table, which is used to match the protocol type corresponding to the header when the header parsing apparatus 500 receives the header, so as to determine which processor is used to parse the header.
Based on the same inventive concept, the embodiment of the application also provides a header parsing device. This header parsing apparatus can be regarded as a specific example of the header parsing apparatus 500 shown in fig. 5. Referring to fig. 8, each of the plurality of cascaded header parsing apparatuses may include a programmable processor, a hardware processor, three data selectors (MUX1, MUX2, and MUX3), and one field extraction module.
The programmable processor includes a register in which a protocol type table (register table) is stored. The programmable processor may be regarded as a specific example of the aforementioned first processor 501, the hardware processor may be regarded as a specific example of the aforementioned second processor 502, the MUX1 may be regarded as a specific example of the aforementioned first data selector, and the MUX2 may be regarded as a specific example of the aforementioned second data selector.
The function of each part in the parsing unit is described in detail below.
1. A programmable processor. The programmable processor supports the protocol type extension after the chip is manufactured, and during implementation, the programmable processor only needs to reserve programmable capacity aiming at possible protocol changes in the life cycle of the chip, and does not need to perform programmable design on the protocol type which is required to be supported by the chip. The configuration information required for the programmable analysis is configured in the register table. The configuration information contained in the register table may refer to the foregoing description, and will not be described herein again.
2. A hardware processor. The implementation of the hardware processor is consistent with the implementation in the prior art, and is used for parsing the header of the inherent protocol type in a hardware manner.
3. MUX 1. The data selector, labeled 1 (i.e., MUX 1), is used to select the Type field of the current layer header according to a first selection signal. The Type field is used to indicate a protocol Type corresponding to a next layer header. Whether parsed by a programmable processor or a hardware processor, the Type field can be obtained from the current layer header. When the programmable processor is adopted for analysis, the MUX1 selects and outputs the analysis result of the programmable processor; when the hardware processor is adopted for analysis, the MUX1 selects and outputs the analysis result of the hardware processor.
4. MUX 2. The data selector (i.e., MUX 2) labeled 2 is used to select the position information of the relevant field to be extracted in the header of the current layer according to the second selection signal. These relevant fields are extracted and can be used for corresponding check checks. Whether parsed by a programmable processor or a hardware processor, the location information of the relevant field can be obtained from the current layer header. When the programmable processor is adopted for analysis, the MUX2 selects and outputs the analysis result of the programmable processor; when the hardware processor is adopted for analysis, the MUX2 selects and outputs the analysis result of the hardware processor. 5. And a field extraction module. And the field extraction module is used for extracting the relevant fields according to the output result of the MUX2 and acquiring the relevant fields for subsequent check and verification.
6. And MUX 3. The data selector labeled 3 (i.e., MUX3) is used to select the parsed result. The MUX3 may select only the parsing result of the current layer header or the previous layer header to output, or may combine the parsing results of the current layer header and the previous layer header to output. The parsing result may include fields extracted from the header, or may include check results of some fields. The MUX3 selects which parsing result to configure according to the user requirement and the protocol requirement.
Based on the same inventive concept, the embodiment of the present application further provides a header parsing method, which can be regarded as a method performed by the header parsing apparatus 500 shown in fig. 5. Referring to fig. 9, the method includes the steps of:
s901: and judging whether the protocol type corresponding to the current layer header in the header of the message to be analyzed is the first protocol type.
S902: analyzing the current layer header through a first processor under the condition that the protocol type corresponding to the current layer header is a first protocol type; the head of the message to be analyzed comprises a multilayer header; and under the condition that the protocol type corresponding to the current layer header is a second protocol type, the current layer header is analyzed through the second processor.
The first protocol type is an extension protocol type, and the second protocol type is an inherent protocol type; the first processor is a processor having programmable processing capabilities and the second processor is a processor having no programmable processing capabilities.
In addition, if the current layer header is not the last layer header, after parsing the current layer header, the type field in the current layer header output by the first processor may be selected and output according to the first selection signal, or the type field in the current layer header output by the second processor may be selected and output according to the first selection signal; the type field in the current layer header is used to indicate the protocol type corresponding to the next layer header of the current layer header.
If the current layer header is the last layer header, after the current layer header is analyzed, the current layer header can be determined to be the last layer header in the header of the message to be analyzed.
In a possible design, if the current layer header is the first layer header in the header of the message to be analyzed, the protocol type corresponding to the current layer header is determined according to the configuration information of the message to be analyzed; if the current layer header is not the first layer header in the header of the message to be analyzed, determining the protocol type corresponding to the current layer header according to the type field in the previous layer header of the current layer header; the type field in the upper layer header of the current layer header is used for indicating the protocol type corresponding to the current layer header.
Optionally, the first processor may further be configured with a register, where a protocol type table is stored in the register, and then, in S901, it is determined whether a protocol type corresponding to a current layer header in a header of the message to be parsed is an operation of the first protocol type, which may specifically be implemented by the following manner: judging whether the protocol type corresponding to the header of the current layer is in the protocol types contained in the protocol type table; if the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is a first protocol type; and if the protocol type corresponding to the current layer header is not in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is not the first protocol type.
In addition, after performing S902 to parse the current layer header, other fields in the current layer header output by the first processor or the second processor may also be extracted; this other field may be used for check checking.
It should be noted that the header parsing method shown in fig. 9 can be regarded as a method performed by the header parsing apparatus 500 shown in fig. 5, and implementation manners and technical effects not described in detail in the header parsing method shown in fig. 9 can be referred to related descriptions in the header parsing apparatus 500 shown in fig. 5.
In addition, an embodiment of the present application further provides a header parsing method, which may be regarded as a specific example of the method shown in fig. 9.
Referring to fig. 10, the method includes the steps of:
1. and judging whether the protocol type corresponding to the current layer header is an extended protocol type or not through register configuration.
The protocol type table is configured in a register, and the judgment of the register configuration is to judge whether the protocol type corresponding to the current layer header is consistent with the protocol type indicated by a certain entry in the protocol type table.
2. If the extension is carried out, the position and the length of other fields in the header of the current layer are obtained according to the register configuration.
3. Other fields in the current layer header are extracted.
4. The extracted other fields are checked.
5. If the judgment in 1 is not extended, extracting or checking other field segments in the header of the current layer according to a hardware analysis mode.
6. It is determined whether a next layer header is present.
7. If the next header exists, repeating 1-6; if not, the resolution is ended.
It should be noted that, in the method shown in fig. 10, only the scheme for parsing fields other than the type field is described, and for the extraction of the type field, reference may be made to the related description in the method shown in fig. 9. In addition, the implementation manner not described in detail in the method shown in fig. 10 can refer to the related description in the method shown in fig. 9, and is not described again here.
In the foregoing embodiments, the description has been made from the viewpoint of parsing the header of the current layer. In order to make the embodiments of the present application easier to understand, two specific embodiments are given below, each of which gives a complete parsing flow for a specific header encapsulation structure.
Example one
In the first embodiment, the package structure shown in fig. 11 needs to be analyzed. Wherein, PORT HDR, IPv8HDR and CDP HDR are all headers of extension protocol type.
When a first layer header (i.e. PORT HDR) is analyzed, a protocol type corresponding to the first layer header is first determined according to configuration information of a packet to be analyzed, and if the protocol type is an extended protocol type, an entry corresponding to the protocol type in a register table is found, as shown in table 1.
TABLE 1
In table 1, HDR LEN indicates that the length of PORT HDR is 16B; TYPE _ VLD indicates the presence of TYPE field in PORT HDR; the TYPE _ OFS indicates that the initial offset of the TYPE field is set as the 8 th B; TYPE _ LEN indicates that the TYPE field length is 2B. The other fields are all 0, indicating that no extraction and checking of the other fields is required. Therefore, 2B content can be extracted starting from the 8 th B, and the 2B content is the Type field we need. The Type field is used to indicate a protocol Type corresponding to a next layer header.
When the second-layer header is analyzed, the Type field extracted by the previous layer is 0xAA88, and there is an entry in the register table that matches the Type field as shown in table 2 (i.e., the Type field of the entry shown in table 2 is also 0xAA88), so the configuration in the register table can be used for analysis when the second-layer header is analyzed.
TABLE 2
Through the above configuration, the length of the IPv8 header is 32B, and after the IPv8 is analyzed, the protocol still needs to be analyzed, that is, the Type field exists, the position is shifted from the IPv8 header by 5B, and the length is 1B. The other fields are all 0, indicating that no extraction and checking of the other fields is required.
When the third-tier header is analyzed, the Type field extracted by the previous tier is 0x5A, and there is an entry in the register table that matches the Type field as shown in table 3 (that is, the Type field of the entry shown in table 3 is also 0x5A), so the configuration in the register table can be used for analysis when the third-tier header is analyzed.
TABLE 3
As can be seen from the above arrangement, the CDP header has a length of 8B, and no header needs to be parsed after the CDP header is parsed, and no Type field exists. However, the F VLD0 field is not 0, i.e., there is a field to extract that starts 48 bits after the CDP header offset and is 16 bits long. The field is directly extracted.
Example two
In the second embodiment, the package structure shown in fig. 12 needs to be analyzed. Wherein, the IPv8HDR is a header of an extended protocol type; MAC HDR, UDP, VxLAN are all inherent protocol type headers.
When the first layer header is analyzed, firstly, a protocol Type corresponding to the first layer header is determined according to configuration information of a message to be analyzed, the protocol Type is an inherent protocol Type, and a hardware analysis mode is directly adopted for analyzing to obtain a Type field in the protocol Type.
When the second-layer header is analyzed, the Type field extracted by the previous layer is 0xAA88, and there is an entry in the register table that matches the Type field as shown in table 4 (that is, the Type field of the entry shown in table 4 is also 0xAA88), so the configuration in the register table can be used for analysis when the second-layer header is analyzed.
TABLE 4
Through the configuration, the length of the IPv8 header is 32B, the protocol needs to be analyzed after the IPv8 is analyzed, the Type field exists, the position is shifted from the IPv8 header by 5B, and the length is 1B. Here, the value of the Type field is 0x11, indicating that the next layer header is a UDP header. The other fields are all 0, indicating that no extraction and checking of the other fields is required.
When the third layer header is analyzed, the Type field extracted by the previous layer is 0x11, and the Type field corresponds to the UDP header and is directly analyzed in a hardware analysis mode. The format of the UDP header is shown in table 5.
TABLE 5
The protocol type corresponding to the next layer header can be identified as VxLAN through Dport (destination port) in the UDP header.
When the fourth layer header is parsed, the VxLAN header is parsed by hardware parsing because VxLAN is an inherent protocol type. In this example, since it is specified that the tunnel inner layer header does not need to be parsed, the parsing is completed after the VXLAN header is parsed.
It will be apparent to those skilled in the art that various changes and modifications may be made in the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. Thus, if such modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to encompass such modifications and variations.
Claims (13)
- A header parsing apparatus, comprising:a first processor, configured to parse the current layer header if a protocol type corresponding to the current layer header is the first protocol type; the head of the message to be analyzed comprises a multilayer header;a second processor, configured to parse the current layer header if a protocol type corresponding to the current layer header is a second protocol type;the first protocol type is an extension protocol type, and the second protocol type is an inherent protocol type; the first processor is a processor having programmable processing capabilities and the second processor is a processor having no programmable processing capabilities.
- The apparatus of claim 1, further comprising:a first data selector for selecting to output the type field in the current layer header output by the first processor according to a first selection signal or selecting to output the type field in the current layer header output by the second processor according to a first selection signal; the type field in the current layer header is used for indicating a protocol type corresponding to a next layer header of the current layer header, and the first selection signal is used for indicating a processor for parsing the current layer header.
- The apparatus of claim 1, wherein the first processor is further to:after the current layer header is analyzed, determining that the current layer header is the last layer header in the headers of the message to be analyzed.
- The apparatus of claim 1, wherein the second processor is further to:after the current layer header is analyzed, determining that the current layer header is the last layer header in the headers of the message to be analyzed.
- The apparatus according to any of claims 1 to 4, wherein if the current layer header is a first layer header in the header of the message to be parsed, a protocol type corresponding to the current layer header is determined according to configuration information of the message to be parsed; if the current layer header is not the first layer header in the header of the message to be analyzed, determining the protocol type corresponding to the current layer header according to the type field in the previous layer header of the current layer header; the type field in the upper layer header of the current layer header is used for indicating the protocol type corresponding to the current layer header.
- The apparatus of any of claims 1-5, wherein the first processor is configured with a register having a protocol type table stored therein, the first processor further configured to:judging whether the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table;if the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is the first protocol type; and if the protocol type corresponding to the current layer header is not in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is not the first protocol type.
- The apparatus of any of claims 1 to 6, further comprising:a second data selector for selecting to output other fields in the current layer header output by the first processor according to a second selection signal or selecting to output the other fields output by the second processor according to a second selection signal; the other fields are used for checking and checking; the second selection signal is used for indicating a processor for analyzing the current layer header;a field extraction module for extracting the other fields output by the second data selector.
- A method of header parsing, comprising:judging whether a protocol type corresponding to a current layer header in a header of a message to be analyzed is a first protocol type;analyzing the current layer header through a first processor under the condition that the protocol type corresponding to the current layer header is the first protocol type; the head of the message to be analyzed comprises a multilayer header; analyzing the current layer header through a second processor under the condition that the protocol type corresponding to the current layer header is a second protocol type;the first protocol type is an extension protocol type, and the second protocol type is an inherent protocol type; the first processor is a processor having programmable processing capabilities and the second processor is a processor having no programmable processing capabilities.
- The method of claim 8, further comprising:selecting to output a type field in the current layer header output by the first processor according to a first selection signal or selecting to output a type field in the current layer header output by the second processor according to a first selection signal; the type field in the current layer header is used for indicating the protocol type corresponding to the next layer header of the current layer header; the first selection signal is used to indicate a processor that parses the current layer header.
- The method of claim 8, after parsing the current layer header, further comprising:and determining the current layer header as the last layer header in the headers of the messages to be analyzed.
- The method according to any one of claims 8 to 10, wherein if the current layer header is a first layer header in the header of the message to be parsed, a protocol type corresponding to the current layer header is determined according to configuration information of the message to be parsed; if the current layer header is not the first layer header in the header of the message to be analyzed, determining the protocol type corresponding to the current layer header according to the type field in the previous layer header of the current layer header; the type field in the upper layer header of the current layer header is used for indicating the protocol type corresponding to the current layer header.
- The method according to any one of claims 8 to 11, wherein a register is configured in the first processor, and a protocol type table is stored in the register, and the determining whether a protocol type corresponding to a current layer header in a header of a packet to be parsed is a first protocol type includes:judging whether the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table;if the protocol type corresponding to the current layer header is in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is the first protocol type; and if the protocol type corresponding to the current layer header is not in the protocol types contained in the protocol type table, determining that the protocol type corresponding to the current layer header is not the first protocol type.
- The method of any one of claims 8 to 12, further comprising:extracting other fields in the current layer header output by the first processor or the second processor; the other fields are used for check checking.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2018/113186 WO2020087400A1 (en) | 2018-10-31 | 2018-10-31 | Header parsing apparatus and method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112136108A true CN112136108A (en) | 2020-12-25 |
Family
ID=70462001
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201880093593.7A Pending CN112136108A (en) | 2018-10-31 | 2018-10-31 | Header analysis device and method |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN112136108A (en) |
| WO (1) | WO2020087400A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114356827A (en) * | 2021-12-23 | 2022-04-15 | 海光信息技术股份有限公司 | Data analysis method, device, equipment and medium |
| WO2023071714A1 (en) * | 2021-10-25 | 2023-05-04 | 中移(苏州)软件技术有限公司 | Message segmented parsing method, apparatus, and device, and storage medium |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112506816B (en) * | 2020-11-26 | 2024-05-03 | 珠海格力电器股份有限公司 | Configuration information analysis method and device |
| CN115242896B (en) * | 2022-07-29 | 2023-06-27 | 宁波三星医疗电气股份有限公司 | Dynamic message parsing method and device, electronic equipment and computer readable storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1500336A (en) * | 2001-03-30 | 2004-05-26 | ŵ�������ܱ�Ե·������˾ | Micro-programmable protocol packet parser and encapsulator |
| US20070058633A1 (en) * | 2005-09-13 | 2007-03-15 | Agere Systems Inc. | Configurable network connection address forming hardware |
| CN103999431A (en) * | 2011-12-22 | 2014-08-20 | 瑞典爱立信有限公司 | System for flexible and extensible flow processing in software-defined networks |
| CN105554002A (en) * | 2015-12-22 | 2016-05-04 | 曙光信息产业股份有限公司 | Tunnel message analyzing method and device |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8681819B2 (en) * | 2011-01-31 | 2014-03-25 | International Business Machines Corporation | Programmable multifield parser packet |
| CN105992186B (en) * | 2015-02-06 | 2020-11-03 | 中兴通讯股份有限公司 | Data transmission method and device |
| CN106850559B (en) * | 2016-12-26 | 2021-07-16 | 中国科学院计算技术研究所 | Extensible network protocol analysis system and method |
-
2018
- 2018-10-31 WO PCT/CN2018/113186 patent/WO2020087400A1/en active Application Filing
- 2018-10-31 CN CN201880093593.7A patent/CN112136108A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1500336A (en) * | 2001-03-30 | 2004-05-26 | ŵ�������ܱ�Ե·������˾ | Micro-programmable protocol packet parser and encapsulator |
| US20070058633A1 (en) * | 2005-09-13 | 2007-03-15 | Agere Systems Inc. | Configurable network connection address forming hardware |
| CN103999431A (en) * | 2011-12-22 | 2014-08-20 | 瑞典爱立信有限公司 | System for flexible and extensible flow processing in software-defined networks |
| CN105554002A (en) * | 2015-12-22 | 2016-05-04 | 曙光信息产业股份有限公司 | Tunnel message analyzing method and device |
Non-Patent Citations (1)
| Title |
|---|
| 曹作伟;陈晓;倪宏;叶晓舟;: "应用于协议无感知转发交换机的流缓存方法", 电子与信息学报, no. 11, 13 July 2018 (2018-07-13) * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023071714A1 (en) * | 2021-10-25 | 2023-05-04 | 中移(苏州)软件技术有限公司 | Message segmented parsing method, apparatus, and device, and storage medium |
| CN114356827A (en) * | 2021-12-23 | 2022-04-15 | 海光信息技术股份有限公司 | Data analysis method, device, equipment and medium |
| CN114356827B (en) * | 2021-12-23 | 2024-03-22 | 海光信息技术股份有限公司 | Data analysis method, device, equipment and medium |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020087400A1 (en) | 2020-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230344922A1 (en) | Configuring a switch for extracting packet header fields | |
| US11425039B2 (en) | Packet header field extraction | |
| CN112136108A (en) | Header analysis device and method | |
| US20240039867A1 (en) | Protocol independent programmable switch (pips) for software defined data center networks | |
| US6771646B1 (en) | Associative cache structure for lookups and updates of flow records in a network monitor | |
| US9398033B2 (en) | Regular expression processing automaton | |
| CN106878194B (en) | Message processing method and device | |
| US8621325B2 (en) | Packet switching system | |
| CN106713144B (en) | Reading and writing method of message outlet information and forwarding engine | |
| CN111935081B (en) | Data packet desensitization method and device | |
| US7373412B2 (en) | Apparatus for selecting and sorting packets from a packet data transmission network | |
| CN113824706B (en) | Message parsing method and network equipment | |
| US20220393908A1 (en) | Message Encapsulation Method and Apparatus, and Message Decapsulation Method and Apparatus | |
| CN107529352B (en) | Protocol Independent Programmable Switch (PIPS) for software defined data center networks | |
| CN112953829B (en) | Flexible parser in network device | |
| US10389626B2 (en) | Transfer device | |
| CN107544928B (en) | Direct memory access control device and method for operating the same | |
| JP2008085886A (en) | Packet processing apparatus, packet processing method, and packet processing program | |
| US20230388253A1 (en) | Packet forwarding system and associated packet forwarding method | |
| CN105763296B (en) | Method for scheduling network frames between processing resources | |
| CN116074404A (en) | Parsing device, message parsing method, forwarding chip and network equipment | |
| CN116866456A (en) | Ethernet message analysis method, system, medium and switch chip | |
| CN117478458A (en) | Message processing method, device and network equipment | |
| CN113055287A (en) | Data packet processing method and device and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |