WO2020087400A1 - Appareil et procédé d'analyse syntaxique d'en-tête - Google Patents

Appareil et procédé d'analyse syntaxique d'en-tête Download PDF

Info

Publication number
WO2020087400A1
WO2020087400A1 PCT/CN2018/113186 CN2018113186W WO2020087400A1 WO 2020087400 A1 WO2020087400 A1 WO 2020087400A1 CN 2018113186 W CN2018113186 W CN 2018113186W WO 2020087400 A1 WO2020087400 A1 WO 2020087400A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
layer header
protocol type
current layer
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.)
Ceased
Application number
PCT/CN2018/113186
Other languages
English (en)
Chinese (zh)
Inventor
青华平
黄欢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201880093593.7A priority Critical patent/CN112136108A/zh
Priority to PCT/CN2018/113186 priority patent/WO2020087400A1/fr
Publication of WO2020087400A1 publication Critical patent/WO2020087400A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

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

Definitions

  • the present application relates to the field of communication technology, and in particular, to a device and method for header analysis.
  • the network device After receiving the message, the network device needs to parse the header, so as to decide how to process the message according to the result of the header analysis.
  • a network device uses hardware parsing to analyze the header layer by layer: the network device performs content identification of different levels of headers from the bottom layer to the upper layer layer by layer, where the operations performed on each layer of headers Is similar. That is, when parsing the header of each layer, a protocol field at a fixed position can be extracted, so that the protocol type of the header of the next layer can be judged according to the protocol field.
  • the network device can also perform corresponding extraction and inspection operations on fields other than the protocol field.
  • the network device first determines the protocol type corresponding to the first layer header as media access control (MAC) according to the configuration of the packet to be parsed, and then determines the first The position of the Type field in the layer header; after parsing the Type field in the first layer header, it is found that the Type field is 0x88A8, and the protocol type corresponding to the second layer header can be determined to be service virtual local area network (service virtual local area network, S- VLAN); At the same time, other fields in the first layer header except Type field can be extracted and checked accordingly.
  • MAC media access control
  • the protocol type corresponding to the second layer header When parsing the second layer header, determine the protocol type corresponding to the second layer header as S-VLAN through the Type field 0x88A8 in the first layer header, and then determine the location of the Type field in the second layer header; resolve the Type field You can know the protocol type corresponding to the third header, and you can also extract and check the fields other than the Type field; after that, each layer of header is parsed in a similar manner until it is parsed to the fifth layer header, that is, user data Report protocol (user datagram protocol, UDP) header. Since the fifth layer header is the last layer header, the relevant fields can be extracted and checked accordingly, and there is no need to extract the Type field.
  • UDP user data Report protocol
  • the chip used to perform the parsing operation can only be used for header parsing of known protocols. If new protocol types appear with the development of technology, it is difficult to support the analysis of new protocol types by using hardware analysis.
  • the embodiments of the present application provide a device and method for parsing a header to improve the scalability of the parsing solution.
  • an embodiment of the present application provides a header parsing device. It includes: a first processor, used to parse the current layer header when the protocol type corresponding to the current layer header is the first protocol type; the header of the packet to be parsed contains multiple layers of headers; the second processor, It is used to parse the current layer header when the protocol type corresponding to the current layer header is the second protocol type.
  • the first protocol type is an extended protocol type
  • the second protocol type is an inherent protocol type
  • the first processor is a processor with programmable processing capabilities
  • the second processing is a processor without programmable processing capabilities
  • the protocol types corresponding to the current layer header include but are not limited to: media access control MAC; business virtual local area network S-VLAN; user virtual local area network C-VLAN; virtual extended local area network VxLAN; Internet Protocol version 4 IPv4; Internet protocol version 6 IPv6; Transmission Control Protocol TCP; User Datagram Protocol UDP; Internet Control Message Protocol ICMP; Dynamic Host Configuration Protocol DHCP.
  • one of the first processor or the second processor may be selected to parse the current layer header according to the protocol type corresponding to the current layer header.
  • the programmable parsing method is used when parsing the current layer header by the first processor
  • the hardware parsing method is used when parsing the current layer header by the second processor. Since the hardware parsing method is used to parse the header of the inherent protocol type and the programmable parsing method is used to parse the header of the extended protocol type, the above scheme can be used to parse both the header of the inherent protocol type and the header of the extended protocol type. To parse. After the chip manufacturing is completed, if the header of the extended protocol type needs to be parsed, the header of the extended protocol type can be parsed only by configuring the reserved programmable capability accordingly, which improves the scalability of the parsing scheme.
  • the header parsing device provided in the first aspect may further include: a first data selector for selecting and outputting the type field in the current layer header output by the first processor according to the first selection signal, or according to the first selection
  • the signal selection output is the type field in the current layer header output by the second processor; 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, and the first selection signal is used to indicate the current
  • the layer header is parsed by the processor.
  • the type field in the header of the current layer can be extracted for parsing the header of the next layer.
  • the first processor or the second processor may also be used: after parsing the current layer header To determine that the current layer header is the last layer header in the header of the packet to be parsed.
  • the first processor or the second processor can determine that the current layer header is the last layer header, and then determine that there is no need to parse the next layer header. At this time, the type field in the current layer header may not be extracted.
  • the protocol type corresponding to the current layer header is determined according to the configuration information of the packet to be parsed; if the current layer header is not The first layer header in the header of the packet to be parsed, the protocol type corresponding to the current layer header is determined according to the type field in the upper layer header of the current layer header; the type field in the upper layer header of the current layer header is used Is used to indicate the protocol type corresponding to the current layer header.
  • a register may be configured in the first processor, and a protocol type table is stored in the register, then the first processor is also used to: determine whether the protocol type corresponding to the current layer header is in the protocol type table Among the included protocol types; if the protocol type corresponding to the current layer header is among the protocol types contained in the protocol type table, it is determined that the protocol type corresponding to the current layer header is the first protocol type; if the protocol type corresponding to the current layer header is not the protocol type Among the protocol types included in the table, it is determined that the protocol type corresponding to the current layer header is not the first protocol type.
  • the header parsing device provided in the first aspect may further include a second data selector and a field extraction module.
  • the second data selector is used to select and output other fields in the current layer header output by the first processor according to the second selection signal, or select and output other fields output by the second processor according to the second selection signal; the other fields It can be used for checking and verification; the second selection signal is used to indicate the processor that parses the current layer header; and the field extraction module is used to extract other fields output by the second data selector.
  • an embodiment of the present application further provides a header parsing method.
  • the method includes the following steps: determining whether the protocol type corresponding to the current layer header in the header of the packet to be parsed is the first protocol type; When the protocol type is the first protocol type, the first processor parses the current layer header; the header of the packet to be parsed contains a multi-layer header; the protocol type corresponding to the current layer header is the second protocol type In this case, the current layer header is parsed by the second processor.
  • the first protocol type is an extended protocol type
  • the second protocol type is an inherent protocol type
  • the first processor is a processor with programmable processing capabilities
  • the second processing is a processor without programmable processing capabilities
  • the method further includes: selecting and outputting the type field in the current layer header output by the first processor according to the first selection signal, or selecting and outputting the output by the second processor according to the first selection signal,
  • the type field in the current layer header; the type field in the current layer header is used to indicate the protocol type corresponding to the header of the next layer of the current layer header;
  • the first selection signal is used to indicate the processor that parses the current layer header.
  • the current layer header after parsing the current layer header, it further includes: determining that the current layer header is the last layer header in the header of the packet to be parsed.
  • the current layer header is the first layer header in the header of the packet to be parsed, and the protocol type corresponding to the current layer header is determined according to the configuration information of the packet to be parsed; if the current layer header is not Parsing the first layer header in the packet header, the protocol type corresponding to the current layer header is determined according to the type field in the upper layer header of the current layer header; the type field in the upper layer header of the current layer header is used for Indicates the protocol type corresponding to the current layer header.
  • a register is configured in the first processor, and a protocol type table is stored in the register to determine whether the protocol type corresponding to the current layer header in the header of the packet to be parsed is the first protocol type, including: Determine whether the protocol type corresponding to the current layer header is in the protocol type included in the protocol type table; if the protocol type corresponding to the current layer header is in the protocol type included in the protocol type table, determine that the protocol type corresponding to the current layer header is the first protocol Type; if the protocol type corresponding to the current layer header is not in the protocol type included in the protocol type table, it is determined that the protocol type corresponding to the current layer header is not the first protocol type.
  • 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 checking and verification.
  • FIG. 1 is a schematic diagram of a header packaging structure provided by the prior art
  • FIG. 2 is a schematic structural diagram of a hardware parsing unit provided by an embodiment of this application.
  • FIG. 3 is a schematic diagram of a packet encapsulation structure provided by an embodiment of this application.
  • FIG. 4 is a schematic diagram of another packet encapsulation structure provided by an embodiment of this application.
  • FIG. 5 is a schematic structural diagram of a first header parsing device provided by an embodiment of this application.
  • FIG. 6 is a schematic structural diagram of a protocol type table provided by an embodiment of this application.
  • FIG. 7 is a schematic structural diagram of a second header parsing device provided by an embodiment of this application.
  • FIG. 8 is a schematic structural diagram of a third header parsing device provided by an embodiment of this application.
  • FIG. 9 is a schematic flowchart of a header parsing method provided by an embodiment of this application.
  • FIG. 10 is a schematic flowchart of another header parsing method provided by an embodiment of this application.
  • FIG. 11 is a schematic diagram of a first header encapsulation structure provided by an embodiment of this application.
  • FIG. 12 is a schematic diagram of a second header encapsulation structure provided by an embodiment of the present application.
  • a network device when it parses a header, it usually adopts a hardware parsing method.
  • the hardware parsing method uses the header recognition module to identify the contents of the header from the bottom to the top. The operation when parsing each layer of headers is similar.
  • the hardware parsing unit shown in FIG. 2 may be used to parse each layer header.
  • the hardware analysis 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 header identification. By identifying the header data, the location of the Type field used to indicate the protocol type of the header of the next layer is known; the field extraction module extracts the relevant fields according to the identification result of the header identification module; The cache module is used to temporarily store 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 content of each field can be transmitted to the Match Engine.
  • the matching engine can parse the information in the header for errors, and parse the protocol type corresponding to the header of the layer below the current layer header.
  • the hardware parsing unit shown in FIG. 2 can only parse headers of a fixed protocol type. If the protocol type corresponding to the header is an extended protocol type, the hardware parsing unit shown in FIG. 2 cannot be used for parsing.
  • embodiments of the present application provide a header parsing device and method for parsing the header when the protocol type corresponding to the multi-layer header includes an extended protocol type, improving the scalability of the parsing method, and at the same time improving the header Analytical efficiency.
  • the method and the device are based on the same inventive concept. Since the principles of the method and the device to solve the problem are similar, the implementation of the device and the method can be referred to each other, and the repetition is not repeated here.
  • each layer header in the multi-layer header may correspond to a known protocol type, or may correspond to an extended protocol type.
  • some headers in the multi-layer header may correspond to a known protocol type, and another header may correspond to an extended protocol type.
  • the packet encapsulation structure shown in FIG. 3 includes a three-layer header.
  • the first layer header supports MAC protocol type and one extended protocol type (TBD1);
  • the second layer header supports fifty known protocol types (such as 1588, IPv4, IPv6, etc.) and one extended protocol type (TBD1);
  • the Layer 3 header supports fifty known protocol types (such as TCP, UDP, etc.) and two extended protocol types (TBD1 and TBD2).
  • the packet encapsulation structure shown in FIG. 4 includes a four-layer header.
  • the first layer header supports MAC protocol types; the second layer header supports fifty known protocol types (such as 1588, IPv4, IPv6, etc.) and one extended protocol type (TBD1); the third layer header supports fifty Known protocol types (such as TCP, UDP, etc.) and two extended protocol types (TBD1 and TBD2); Layer 4 header supports sixty-four known protocol types (such as DHCP, VxLAN, etc.) and one extended protocol type (TBD1).
  • the header parsing device 500 includes a first processor 501 and a second processor 502.
  • the first processor 501 is configured to parse the current layer header when the protocol type corresponding to the current layer header is the first protocol type; the header of the packet to be parsed includes multiple layers of headers.
  • the second processor 502 is configured to parse the current layer header when the protocol type corresponding to the current layer header is the second protocol type.
  • the first protocol type is an extended protocol type
  • the second protocol type is an inherent protocol type
  • the first processor 501 is a processor with programmable processing capabilities
  • the second processing is a processor without programmable processing capabilities.
  • 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 the protocol type that has appeared before the header parsing device 500 is manufactured.
  • the headers of these protocol types can be parsed by the second processor 502 using hardware parsing;
  • the first protocol type can be understood as the protocol types that appear after the header parsing device 500 is manufactured, and the headers of these protocol types can be passed by the first processor 501 uses a programmable analysis method for analysis.
  • the protocol types corresponding to the current layer header include but are not limited to medium access control (medium access control (MAC); service virtual local area network (service virtual local area network, S-VLAN); user virtual local area network (customer virtual local area (network, C-VLAN); virtual extended local area network (virtual extensible local area network, VxLAN); Internet Protocol version 4 (internet protocol version 4, IPv4); Internet Protocol version 6 (internet protocol version 6, IPv6); transmission Control protocol (transmission control protocol, TCP); user datagram protocol (user datagram protocol, UDP); Internet control message protocol (internet control message protocol, ICMP); dynamic host configuration protocol (dynamic host configuration protocol, DHCP).
  • medium access control medium access control
  • S-VLAN service virtual local area network
  • user virtual local area network customer virtual local area (network, C-VLAN); virtual extended local area network (virtual extensible local area network, VxLAN
  • Internet Protocol version 4 Internet protocol version 4, IPv4
  • Internet Protocol version 6 Internet protocol version 6, IPv6
  • transmission Control protocol
  • protocol types corresponding to the current layer header are only examples. In practical applications, the protocol types corresponding to the current layer header are not limited to the cases listed in the above examples.
  • the current layer header may be the first layer header or other layer headers other than the first layer header.
  • the first layer header is a MAC header
  • other headers include an S-VLAN header, a C-VLAN header, and so on.
  • the manner of determining the protocol type corresponding to the current layer header is different.
  • the protocol type corresponding to the current layer header can be determined according to the configuration information of the packet to be parsed.
  • the protocol type corresponding to the first layer header can be determined by the port configuration information of the packet to be parsed, that is, the protocol type corresponding to the first layer header can be determined by the port that receives the packet to be parsed.
  • the protocol type corresponding to the first layer header may be MAC or Fibre Channel (FC).
  • the protocol type corresponding to the current layer header can be determined according to the type field in the upper layer header of the current layer header, where the type field in the upper layer header of the current layer header is used to indicate the current layer header The corresponding protocol type. In other words, by parsing the header of the upper layer, the type field in the header of the upper layer can be obtained, and then the protocol type corresponding to the header of the current layer can be learned.
  • the type field may also be called a Type field.
  • the protocol type corresponding to the current layer header is determined according to the configuration information of the packet to be parsed; if the current layer header is not the packet to be parsed The first layer header in the header of the header, then the protocol type corresponding to the current layer header is determined according to the type field in the upper layer header of the current layer header; the type field in the upper layer header of the current layer header is used to indicate The protocol type corresponding to the header.
  • the operation of determining the protocol type corresponding to the current layer header may be performed by the first processor 501, may be performed by the second processor 502, or may be performed by a separate module.
  • the execution subject performing the operation is not specifically limited.
  • the first processor 501 may determine whether the protocol type corresponding to the current layer header is the first protocol type. If it is, the first processor 501 parses the current layer header. The second process 502 performs protocol type matching. If the matching is successful, the second processor 502 parses the current layer header; if the matching fails, the current layer header parsing will report an error.
  • the manner in which the second processor 502 performs protocol type matching is in the prior art, and will not be repeated here. The specific manner in which the first processor 502 determines whether the protocol type corresponding to the current layer header is the first protocol type is described below.
  • a register may be configured in the first processor 501, and a protocol type table may be stored in the register. Then, the first processor 501 determines whether the protocol type corresponding to the current layer header in the header of the packet to be parsed When it is the first protocol type, it can be specifically implemented by determining whether the protocol type corresponding to the current layer header is in the protocol type included in the protocol type table; if the protocol type corresponding to the current layer header is in the protocol type included in the protocol type table , It is determined that the protocol type corresponding to the current layer header is the first protocol type; if the protocol type corresponding to the current layer header is not among the protocol types included in the protocol type table, it is determined that the protocol type corresponding to the current layer header is not the first protocol type.
  • the protocol type table is used to indicate the protocol type corresponding to the header that can be parsed by the first processor 501. That is, in order to determine which protocol type headers can be parsed by the first processor 501 in a programmable parsing manner, an embodiment of the present application maintains a protocol type table, which can be implemented using configuration registers (ie, the protocol The type table is stored in the configuration register).
  • the first processor 501 If the protocol type corresponding to the current layer header is in the protocol type contained in the protocol type table (that is, the protocol type corresponding to the current layer header is the same as the protocol type of an entry in the protocol type table), the first processor 501 The header is parsed; if the protocol type corresponding to the current layer header is not in the protocol type contained in the protocol type table (that is, the protocol type corresponding to the current layer header is inconsistent with the protocol type of any entry in the protocol type table), then pass the second processor 502 Parse the current layer header.
  • the protocol type table may also include other configuration information of the current layer header.
  • 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 other fields in the current layer header other than the type field are used to indicate the protocol type corresponding to the next layer header of the current layer header; other fields can be used for corresponding check and verification.
  • the protocol type table may also be referred to as register table.
  • the configuration information contained in each entry of register may be as shown in FIG. 6.
  • the Type field indicates the protocol type number indicated by the entry, that is, the value of the Type field extracted from the header of the upper layer is equal to the value of the Type field in the register table, indicating that the new protocol is hit and needs to pass the first processor 501 Parse the current layer header.
  • HDR_LEN represents the length of the current layer header in Byte.
  • TYPE_OFS indicates the offset of the Type field in the current layer header used to indicate the protocol type corresponding to the header of the next layer, in bytes.
  • TYPE_LEN indicates the length of the Type field in the current layer header used to indicate the protocol type corresponding to the header of the next layer, in Byte.
  • F_OFSn / F_LENn indicates the offset position and length of other fields except the Type field in the current layer header, all of which are in bits. Four other fields are defined in the entry shown in FIG. 6.
  • TYPE_VLD / F_VLDn can be set to 1 or cleared to indicate whether the corresponding field needs to be extracted and identified. For example, when F_VLD1 is 1, it means that the offset position is F_OFS1 and the field with length F_LEN1 needs to be extracted and identified.
  • the header parsing device 500 may further include a first data selector.
  • the first data selector may select and output the type field in the current layer header output by the first processor 501 according to the first selection signal, Or select and output the type field in the current layer header output by the second processor 502 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, and the first selection signal is used to indicate a processor that parses the current layer header.
  • the first selection signal may be output by the first processor 501 to the first data selector after determining whether the protocol type corresponding to the current layer header in the header of the packet to be parsed is the first protocol type; specifically, the first After determining that the protocol type corresponding to the current layer header is the first protocol type, the processor 501 may determine to parse the current layer header by itself. At this time, the first processor 501 may output the first selection signal to the first data selector.
  • the first processor 501 is a processor instructing to parse the current layer header.
  • the first selection signal may also be output by the second processor 502 to the first data selector.
  • the second processor 502 may determine that the current layer header is parsed by itself when the protocol type corresponding to the current layer header is the second protocol type. At this time, the second processor 502 may output to the first data selector The first selection signal indicates that the processor that parses 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 it is the first processor 501 that parses 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 current layer header is Parsing the second processor 502, 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.
  • the type field of the current layer header output by the first data selector is the Type field in the MAC header, and the Type field is used It indicates the protocol type corresponding to the next layer header (ie S-VLAN header) of the current layer header (ie MAC header).
  • the first processor 501 or the second processor 502 may determine the current layer according to the analysis result
  • the header is the last header in the header of the packet to be parsed.
  • the header parsing device 500 may further include a second data selector and a field extraction module.
  • the second data selector may be used to select and output other data in the current layer header output by the first processor 501 according to the second selection signal.
  • the second selection signal is used to indicate the parsing of the current layer header Processor;
  • the field extraction module can be used to extract other fields output by the second data selector.
  • the functions of the second selection signal and the first selection signal are similar, and are not repeated here.
  • 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 it is the first processor 501 that parses 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 current layer header is performed Parsing the second processor 502, 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.
  • the field extraction module After the field extraction module outputs other fields, other devices (such as a matching engine) can check and verify the other fields.
  • the inspection and verification of other fields can be divided into two types: the first is the correctness check of the protocol fields.
  • the protocol type corresponding to the current layer header has requirements on the meaning and assignment of certain fields, and the legitimacy of the current layer header is recognized only if the meaning and assignment of the field meet the requirements. For example, IPv4 requires that the version field must be 4, then, if the protocol type corresponding to the current layer header is IPv4, you need to extract the version field and check the version field. If the version field is assigned a value of 4, the check passes; if the version field is assigned a value of 4, an error will be reported.
  • the second is based on user requirements, flexible and configurable field value check. In certain scenarios, users can have special requirements for the assignment of certain fields.
  • the inspection can pass. For example, you can specify that the common flash interface (CFI) field in the S-VLAN is the same as the CFI field configured by you. If the protocol type corresponding to the current layer header is S-VLAN, you need to extract the CFI field and Check the CFI field. If the assignment of the CFI field is consistent with its own configuration, the check is passed; if the assignment of the CFI field is inconsistent with its own configuration, an error will be reported.
  • CFI common flash interface
  • checking other fields is optional. That is, the agreement may specify that other fields need to be checked, or that other fields may not be checked; or, the user configuration may indicate that other fields are checked, or that other fields are not checked.
  • the header parsing device 500 when the header parsing device 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 device 500 may be as shown in FIG. 7 .
  • the current layer header may be deleted from the header of the packet to be parsed, and then passed to the next layer to continue parsing.
  • the type field in the current layer header needs to be used by the next layer to determine the protocol type for parsing, the type field in the current layer header should also be passed to the next layer. That is to say, after the field extraction module extracts the type field in the current layer header, the header of the packet to be parsed can also be output to the next layer by deleting the part after the current layer header and the type field in the current layer header, Used to parse the next layer header of the current layer header.
  • the current layer header is the MAC header in FIG. 1, after parsing the current layer header, the Type field in the MAC header and the S-VLAN header, C-VLAN header, and IPv4 header after the MAC header can be And the UDP header is passed to the next layer for analysis.
  • one of the first processor 501 or 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 first processor 501 adopts a programmable parsing method when parsing the current layer header
  • the second processor 502 adopts a hardware parsing method when parsing the current layer header. Since the hardware parsing method is used to parse the header of the inherent protocol type and the programmable parsing method is used to parse the header of the extended protocol type, the solution provided by the embodiment of the present application can both parse the header of the inherent protocol type and The header of the extended protocol type is parsed. After the chip manufacturing is completed, if the header of the extended protocol type needs to be parsed, the header of the extended protocol type can be parsed only by configuring the reserved programmable capability accordingly, which improves the scalability of the parsing scheme.
  • the header of the protocol type that can be determined at the design stage can be parsed using a hardware parsing method.
  • the extended protocol type only a certain programmability needs to be reserved to pass the protocol type table.
  • the extended protocol type is configured so that the header of the extended protocol type is parsed in a programmable manner, and the user configuration is simple.
  • it is only necessary to determine whether the protocol type corresponding to the current layer header is among the protocol types included in the protocol type table.
  • the solution provided by the embodiment of the present application is used to determine which processor is used for parsing the header of the current layer, and the number of search matches is less, so that the delay of header parsing can be reduced and the parsing efficiency can be improved. At the same time, it can also save the realization area of the chip and reduce the design complexity.
  • the header of the packet to be parsed includes multiple layers of headers corresponding to multiple protocol types, and parsing of each layer of headers can be performed by the above-mentioned header parsing apparatus 500. That is to say, when parsing the entire header of the packet to be parsed, it can be executed by a plurality of cascading header parsing devices 500, and each header parsing device 500 is used to parse a layer of headers. Specifically, when parsing the header of each layer 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 for matching the protocol type corresponding to the header when the header parsing device 500 receives the header, so as to determine which processor is used to parse the header.
  • each header parsing device may include a programmable processor, a hardware processor, three data selectors (MUX1, MUX2, and MUX3) and a field extraction module.
  • the programmable processor includes a register, and the register stores a protocol type table (register) table.
  • the programmable processor can be regarded as a specific example of the aforementioned first processor 501
  • the hardware processor can be regarded as a specific example of the aforementioned second processor 502
  • MUX1 can be considered as a specific example of the aforementioned first data selector
  • MUX2 can be regarded as a specific example of the aforementioned second data selector.
  • Programmable processor supports the expansion of the protocol type after the chip manufacturing is completed. In the implementation, the programmable processor only needs to reserve the programmability for possible protocol changes during the chip life cycle, and does not need to support the protocol type that the chip needs to support. Programmable design.
  • the configuration information required for programmable analysis is configured in the register. Among them, the configuration information contained in the register table can refer to the previous introduction, and will not be repeated here.
  • Hardware processor The implementation of the hardware processor is consistent with the implementation in the prior art, and is used to parse the header of the inherent protocol type in a hardware manner.
  • MUX 1 The data selector labeled 1 (that is, MUX1) is used to select the Type field of the current layer header according to the first selection signal.
  • the Type field is used to indicate the protocol type corresponding to the header of the next layer.
  • the Type field can be obtained from the current layer header whether it is parsed by a programmable processor or a hardware processor.
  • MUX1 selects the analysis result of the programmable processor and outputs it; when using a hardware processor for analysis, MUX1 selects the analysis result of the hardware processor and outputs it.
  • MUX 2 The data selector labeled 2 (that is, MUX 2) is used to select the position information of the relevant field to be extracted in the current layer header according to the second selection signal. After these related fields are extracted, they can be used for corresponding inspection and verification. Whether it is parsed by a programmable processor or a hardware processor, the position information of the relevant field can be obtained from the current layer header. When using a programmable processor for analysis, MUX 2 selects the analysis result of the programmable processor and outputs it; when using a hardware processor for analysis, MUX 2 selects the analysis result of the hardware processor and outputs it. 5. Field extraction module. The field extraction module is used to extract related fields according to the output result of MUX2 and obtain related fields for subsequent inspection and verification.
  • MUX3 The data selector labeled 3 (that is, MUX3) is used to select the analysis result.
  • MUX3 can select only the parsing result of the current layer header or the previous layer header output, or can combine the parsing result of the current layer header and the previous layer header to output.
  • the parsing result may contain the fields extracted from the header, and may also contain the verification results of certain fields.
  • MUX3 chooses which analysis result can be configured according to user needs and protocol requirements.
  • embodiments of the present application also provide a header parsing method, which can be regarded as a method performed by the header parsing apparatus 500 shown in FIG. 5.
  • the method includes the following steps:
  • S901 Determine whether the protocol type corresponding to the current layer header in the header of the packet to be parsed is the first protocol type.
  • the first processor parses the current layer header; the header of the packet to be parsed contains a multi-layer header; the protocol corresponding to the current layer header When the type is the second protocol type, the current layer header is parsed by the second processor.
  • the first protocol type is an extended protocol type
  • the second protocol type is an inherent protocol type
  • the first processor is a processor with programmable processing capabilities
  • the second processing is a processor without programmable processing capabilities
  • the type field in the current layer header output by the first processor can also be selected and output according to the first selection signal, or according to the first The selection signal selects and outputs the type field in the current layer header output by the second processor; 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.
  • the current layer header is the last layer header, after parsing the current layer header, it can be determined that the current layer header is the last layer header in the header of the packet to be parsed.
  • the protocol type corresponding to the current layer header is determined according to the configuration information of the packet to be parsed; if the current layer header is not The first layer header in the header of the packet to be parsed, the protocol type corresponding to the current layer header is determined according to the type field in the upper layer header of the current layer header; the type field in the upper layer header of the current layer header is used Is used to indicate the protocol type corresponding to the current layer header.
  • the first processor may also be configured with a register, which stores a protocol type table. Then, in S901, it is determined whether the protocol type corresponding to the current layer header in the header of the packet to be parsed is the first protocol type
  • the operation can be achieved by: determining whether the protocol type corresponding to the current layer header is in the protocol type included in the protocol type table; if the protocol type corresponding to the current layer header is in the protocol type included in the protocol type table, determine the current The protocol type corresponding to the layer header is the first protocol type; if the protocol type corresponding to the current layer header is not among the protocol types included in the protocol type table, it is determined that the protocol type corresponding to the current layer header is not the first protocol type.
  • header parsing method shown in FIG. 9 can be regarded as a method performed by the header parsing device 500 shown in FIG. 5, and implementation methods and technical effects that are not described in detail in the header parsing method shown in FIG. 9 can be referred to The related description in the header parsing apparatus 500 shown in FIG. 5.
  • the embodiment of the present application also provides a header parsing method, which can be regarded as a specific example of the method shown in FIG. 9.
  • the method includes the following steps:
  • the protocol type table is configured in a register, and judging the register configuration is to determine whether the protocol type corresponding to the current layer header is consistent with the protocol type indicated by an entry in the protocol type table.
  • PORT HDR, IPv8HDR, CDP HDR are the headers of the extended protocol type.
  • the protocol type is an extended protocol type, then find the protocol type in the register table The corresponding entries are shown in Table 1.
  • HDR_LEN indicates that the length of PORT HDR is 16B; TYPE_VLD indicates that there is a Type field in PORT HDR; TYPE_OFS indicates that the start offset of the Type field is the 8th B; TYPE_LEN indicates that the Type field length is 2B. All other fields are 0, which means that there is no need to extract and check other fields. Therefore, we can extract the 2B content from the 8th B, which is the Type field we need.
  • the Type field is used to indicate the protocol type corresponding to the header of the next layer.
  • the Type field extracted by the previous layer is 0xAA88, and the entries shown in Table 2 in the register table match the Type field (that is, the Type field of the entry shown in Table 2 is also 0xAA88), so you can use the configuration in the register table to parse the second layer header.
  • the length of the IPv8 header is 32B. After parsing IPv8, there are still protocols that need to be parsed. That is, there is a Type field, and the position is 5B after the offset from the IPv8 header. All other fields are 0, which means that there is no need to extract and check other fields.
  • the Type field extracted by the previous layer is 0x5A, and there are entries in the register table as shown in Table 3 that match the Type field (that is, the Type field of the entry shown in Table 3 is also 0x5A), so when parsing the layer 3 header, you can use the configuration in the register table for parsing.
  • the length of the CDP header is 8B.
  • the F_VLD0 field is not 0, that is, there is a field that needs to be extracted, the position is offset from the CDP header by 48 bits, and the length is 16 bits. Simply extract the field.
  • IPv8HDR is the header of the extended protocol type
  • MAC, HDR, UDP, and VxLAN are all the headers of the inherent protocol type.
  • the protocol type is an inherent protocol type, which is directly parsed by hardware parsing to obtain the Type Field.
  • the Type field extracted by the previous layer is 0xAA88, and there are entries in the register shown in Table 4 that match the Type field (that is, the Type field of the entry shown in Table 4 is also 0xAA88), so you can use the configuration in the register table to parse the second layer header.
  • the length of the IPv8 header is 32B. After parsing the IPv8, there is still a protocol that needs to be parsed. There is a Type field. The position is 5B from the IPv8 header, and the length is 1B. The value of the Type field here is 0x11, indicating that the next layer header is a UDP header. All other fields are 0, which means that there is no need to extract and check other fields.
  • the Type field extracted by the previous layer is 0x11, which corresponds to the UDP header and is directly parsed by hardware parsing.
  • the format of UDP header is shown in Table 5.
  • the protocol type corresponding to the header of the next layer can be identified as VxLAN.
  • VxLAN is an inherent protocol type
  • the VxLAN header is parsed using hardware parsing. In this example, it is stipulated that there is no need to parse the tunnel inner header, so the parsing ends after parsing the VXLAN header.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un appareil et un procédé d'analyse syntaxique d'en-tête, utilisés pour améliorer l'extensibilité d'une solution d'analyse syntaxique. L'appareil comprend un premier processeur et un deuxième processeur ; le premier processeur étant utilisé pour effectuer une analyse syntaxique d'un en-tête de couche actuelle dans des conditions où un type de protocole correspondant à l'en-tête de couche actuelle est un premier type de protocole ; un en-tête d'un paquet devant subir une analyse syntaxique contenant de multiples en-têtes de couche ; le deuxième processeur étant utilisé pour effectuer une analyse syntaxique d'un en-tête de couche actuelle dans des conditions où un type de protocole correspondant à l'en-tête de couche actuelle est un deuxième type de protocole ; le premier type de protocole étant un type de protocole d'extension, et le deuxième type de protocole étant un type de protocole fixe ; le premier processeur étant un processeur ayant une fonctionnalité de traitement programmable, et le deuxième processeur étant un processeur n'ayant pas de fonctionnalité de traitement programmable.
PCT/CN2018/113186 2018-10-31 2018-10-31 Appareil et procédé d'analyse syntaxique d'en-tête Ceased WO2020087400A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201880093593.7A CN112136108A (zh) 2018-10-31 2018-10-31 一种报头解析装置及方法
PCT/CN2018/113186 WO2020087400A1 (fr) 2018-10-31 2018-10-31 Appareil et procédé d'analyse syntaxique d'en-tête

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/113186 WO2020087400A1 (fr) 2018-10-31 2018-10-31 Appareil et procédé d'analyse syntaxique d'en-tête

Publications (1)

Publication Number Publication Date
WO2020087400A1 true WO2020087400A1 (fr) 2020-05-07

Family

ID=70462001

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/113186 Ceased WO2020087400A1 (fr) 2018-10-31 2018-10-31 Appareil et procédé d'analyse syntaxique d'en-tête

Country Status (2)

Country Link
CN (1) CN112136108A (fr)
WO (1) WO2020087400A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112506816A (zh) * 2020-11-26 2021-03-16 珠海格力电器股份有限公司 配置信息解析方法和装置
CN115242896A (zh) * 2022-07-29 2022-10-25 宁波三星医疗电气股份有限公司 动态报文解析方法、装置、电子设备及计算机可读存储介质
CN115412619A (zh) * 2022-07-21 2022-11-29 浙江众合科技股份有限公司 一种用户可配置报文格式的日志报文实时监听及解析方法
CN115633103A (zh) * 2022-09-01 2023-01-20 篆芯半导体(南京)有限公司 数据包的混合解析方法及系统
WO2024250784A1 (fr) * 2023-06-09 2024-12-12 大唐移动通信设备有限公司 Procédé et appareil de traitement de paquets de données, ainsi que dispositif électronique
CN120751040A (zh) * 2025-08-14 2025-10-03 北京玄戒技术有限公司 网络报文解析方法、装置、电子设备和存储介质
US12489833B2 (en) 2021-10-30 2025-12-02 Huawei Technologies Co., Ltd. Parsing component, packet parsing method, forwarding chip, and network device

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116033044B (zh) * 2021-10-25 2024-10-25 中移(苏州)软件技术有限公司 报文的分段解析方法、装置、设备和存储介质
CN114356827B (zh) * 2021-12-23 2024-03-22 海光信息技术股份有限公司 数据解析方法、装置、设备及介质
CN116320086A (zh) * 2023-03-03 2023-06-23 篆芯半导体(南京)有限公司 一种基于协同解析的tcam报文处理方法、装置及介质
CN119094633B (zh) * 2023-06-05 2025-11-11 比亚迪股份有限公司 一种基于状态机的报文解析方法、装置及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1500336A (zh) * 2001-03-30 2004-05-26 ŵ�������ܱ�Ե·������˾ 可编微程序的协议包解析程序和封装程序
US20120195208A1 (en) * 2011-01-31 2012-08-02 International Business Machines Corporation Programmable multifield parser packet
CN105992186A (zh) * 2015-02-06 2016-10-05 中兴通讯股份有限公司 数据传输方法及装置
CN106850559A (zh) * 2016-12-26 2017-06-13 中国科学院计算技术研究所 一种可扩展的网络协议解析系统及方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7599364B2 (en) * 2005-09-13 2009-10-06 Agere Systems Inc. Configurable network connection address forming hardware
US8521905B2 (en) * 2011-12-22 2013-08-27 Telefonaktiebolaget L M Ericsson (Publ) System for flexible and extensible flow processing in software-defined networks
CN105554002A (zh) * 2015-12-22 2016-05-04 曙光信息产业股份有限公司 一种隧道报文的解析方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1500336A (zh) * 2001-03-30 2004-05-26 ŵ�������ܱ�Ե·������˾ 可编微程序的协议包解析程序和封装程序
US20120195208A1 (en) * 2011-01-31 2012-08-02 International Business Machines Corporation Programmable multifield parser packet
CN105992186A (zh) * 2015-02-06 2016-10-05 中兴通讯股份有限公司 数据传输方法及装置
CN106850559A (zh) * 2016-12-26 2017-06-13 中国科学院计算技术研究所 一种可扩展的网络协议解析系统及方法

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112506816A (zh) * 2020-11-26 2021-03-16 珠海格力电器股份有限公司 配置信息解析方法和装置
CN112506816B (zh) * 2020-11-26 2024-05-03 珠海格力电器股份有限公司 配置信息解析方法和装置
US12489833B2 (en) 2021-10-30 2025-12-02 Huawei Technologies Co., Ltd. Parsing component, packet parsing method, forwarding chip, and network device
CN115412619A (zh) * 2022-07-21 2022-11-29 浙江众合科技股份有限公司 一种用户可配置报文格式的日志报文实时监听及解析方法
CN115412619B (zh) * 2022-07-21 2024-06-04 浙江众合科技股份有限公司 一种用户可配置报文格式的日志报文实时监听及解析方法
CN115242896A (zh) * 2022-07-29 2022-10-25 宁波三星医疗电气股份有限公司 动态报文解析方法、装置、电子设备及计算机可读存储介质
CN115242896B (zh) * 2022-07-29 2023-06-27 宁波三星医疗电气股份有限公司 动态报文解析方法、装置、电子设备及计算机可读存储介质
CN115633103A (zh) * 2022-09-01 2023-01-20 篆芯半导体(南京)有限公司 数据包的混合解析方法及系统
CN115633103B (zh) * 2022-09-01 2024-08-13 篆芯半导体(南京)有限公司 数据包的混合解析方法及系统
WO2024250784A1 (fr) * 2023-06-09 2024-12-12 大唐移动通信设备有限公司 Procédé et appareil de traitement de paquets de données, ainsi que dispositif électronique
CN120751040A (zh) * 2025-08-14 2025-10-03 北京玄戒技术有限公司 网络报文解析方法、装置、电子设备和存储介质

Also Published As

Publication number Publication date
CN112136108A (zh) 2020-12-25

Similar Documents

Publication Publication Date Title
WO2020087400A1 (fr) Appareil et procédé d'analyse syntaxique d'en-tête
CN104144156B (zh) 报文处理方法和装置
CN115883681B (zh) 报文解析方法、装置、电子设备及存储介质
CN104702588B (zh) 解析器、分组处理装置以及相关方法
US6771646B1 (en) Associative cache structure for lookups and updates of flow records in a network monitor
US8681819B2 (en) Programmable multifield parser packet
US10348603B1 (en) Adaptive forwarding tables
CN111935081B (zh) 一种数据包脱敏方法和装置
US10057162B1 (en) Extending Virtual Routing and Forwarding at edge of VRF-aware network
CN106330776A (zh) 报文处理方法及装置
US20130156036A1 (en) Analysis of network packets using a generated hash code
US10616105B1 (en) Extending virtual routing and forwarding using source identifiers
WO2023071714A1 (fr) Procédé, appareil et dispositif d'analyse segmentée de message et support de stockage
JP7480907B2 (ja) 変換装置、変換方法及び変換プログラム
EP2919433A1 (fr) Procédé et dispositif de traitement de protocole de communication
CN116634046A (zh) 报文处理方法、装置、电子设备及存储介质
CN118714070A (zh) 数据处理方法、装置及电子设备
CN116847005B (zh) 报文解析方法、解析器件及网络设备
CN116708609B (zh) 报文字符数据的提取方法和装置、存储介质及电子装置
US12137049B1 (en) Extending virtual routing and forwarding
CN114995878B (zh) 一种自动生成网络数据转发面驱动代码的方法
CN105515995B (zh) 报文处理方法及装置
US20090285207A1 (en) System and method for routing packets using tags
US10374950B2 (en) Routing traffic between networks governed by different versions of the internet protocol
US20110158119A1 (en) Communication apparatus, processing method for the same, and computer-readable storage medium

Legal Events

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

Ref document number: 18938911

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18938911

Country of ref document: EP

Kind code of ref document: A1