US6611524B2 - Programmable data packet parser - Google Patents

Programmable data packet parser Download PDF

Info

Publication number
US6611524B2
US6611524B2 US09/340,256 US34025699A US6611524B2 US 6611524 B2 US6611524 B2 US 6611524B2 US 34025699 A US34025699 A US 34025699A US 6611524 B2 US6611524 B2 US 6611524B2
Authority
US
United States
Prior art keywords
data
packet
comparison result
database
signature word
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.)
Expired - Lifetime
Application number
US09/340,256
Other versions
US20030108038A1 (en
Inventor
Harish Devanagondi
James Sun
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.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cisco Technology Inc filed Critical Cisco Technology Inc
Priority to US09/340,256 priority Critical patent/US6611524B2/en
Assigned to CISCO TECHNOLOGY INC. reassignment CISCO TECHNOLOGY INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DEVANAGONDI, HARISH, SUN, JAMES
Publication of US20030108038A1 publication Critical patent/US20030108038A1/en
Application granted granted Critical
Publication of US6611524B2 publication Critical patent/US6611524B2/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/901Buffering arrangements using storage descriptor, e.g. read or write pointers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9063Intermediate storage in different physical parts of a node or terminal
    • H04L49/9068Intermediate storage in different physical parts of a node or terminal in the network interface card
    • H04L49/9073Early interruption upon arrival of a fraction of a packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q11/00Selecting arrangements for multiplex systems
    • H04Q11/04Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478Provisions for broadband connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • H04L12/5601Transfer mode dependent, e.g. ATM
    • H04L2012/5638Services, e.g. multimedia, GOS, QOS
    • H04L2012/5646Cell characteristics, e.g. loss, delay, jitter, sequence integrity
    • H04L2012/5651Priority, marking, classes

Definitions

  • the present invention relates to an apparatus and method for parsing data packets having different formats and in particular to parsing which is programmable, e.g. to accommodate new or different formats, but which can be provided without the need for using a microprocessor for parsing.
  • a number of electronic devices can receive data packets which may be in any of a plurality of different formats, which may not be known in advance. Examples include network routers, gateways, bridges, hubs and the like. Typically, information is included in the packets which is useful in determining how to handle or process the packets. For example, packets may include information regarding the destination of the packet, the size of the packet (or various fields therein) and the like. There are, however, a plurality of different formats for data packets and the location of information within various data packets may differ in the various formats. For example, one format may provide destination information in bytes 30 through 33 of a packet while another may provide destination information in bytes 38 through 41 .
  • parsing the packet In order to properly handle a data packet, it is typically necessary to determine the format of the data packet.
  • the parsing of network data packets presents certain challenges which are believed substantially unique compared to other types of parsing. For example, typically the time available for parsing a packet is driven by the rate at which packets arrive, i.e. a given packet typically must be fully parsed before the next packet arrives. In a typical situation it is substantially infeasible to predict the format of the next packet, i.e. packets may arrive in substantially random formats. In many situations, a given type of data, although positioned in different locations for different formats, nevertheless may be used in substantially the same way for different formats. For example, although destination information may be located at different places for differently formatted packets, the destination information is used in substantially the same way for handling many, if not all, of the differently-formatted packets.
  • a microprocessor or an embedded microcoded engine, executes microcode which performs a plurality of (typically sequential) tests or comparisons on various data and/or fields of the packet to determine the packet format.
  • An advantageous aspect of this approach is that the system can be configured to accommodate new packet formats by revising the microcode, i.e. substantially without the need for redesigning hardware (such as without the need for redesigning the microprocessor).
  • this approach can be relatively expensive. If a microprocessor is used for parsing packets, the cost of the microprocessor can undesirably increase the cost of the network router or other apparatus.
  • microprocessor If the microprocessor is also being used for other purposes, there can still be substantial expense involved because it is necessary to provide a processor which has a sufficiently high performance that it can perform both parsing functions and other functions and can perform such functions quickly enough to accommodate the data rates or data speeds of the incoming packets.
  • providing a microprocessor for packet parsing functions can involve providing a processor which has higher performance (and typically higher cost) than would otherwise be necessary. Accordingly, it would be useful to provide a packet parser which can be implemented in an economic fashion preferably without the need to use a microprocessor or an embedded microcoded engine for packet parsing functions.
  • hardwired logic may be configured to test a first predefined field or bit of each incoming packet and, depending on the result of the comparison, branching to a next comparison for a second field or bit of the packet. This procedure is repeated recursively until the packet is parsed.
  • Each test, in this configuration is performed by hardwired logic and, accordingly, one disadvantageous aspect of such an approach is that new or different formats cannot be accommodated with a change in programming or software. Rather, when the hardwired logic is implemented, e.g., in an application specific integrated circuit (ASIC), a new or different format for packets requires redesigning the hardwired logic and generating a new ASIC, typically at substantial expense.
  • ASIC application specific integrated circuit
  • a data packet parser which can accommodate new or changed data packet formats without the need for changing or redesigning hardwired logic or other hardware, preferably by merely making software or programming changes and preferably in a way such that a new or changed packet format can be accommodated without the need for redesigning an entire logic tree.
  • the present invention provides a method and apparatus for parsing data packets without the need for using a microprocessor to achieve such parsing, yet which can accommodate new or different packet formats without the need for changing hardwired logic or other circuitry or hardware (such as by changing programming or software).
  • a database is stored, e.g. such as storing in a plurality of registers, which is used in providing a signature word for each packet, with the signature words being indicative of particular packet formats.
  • New or different formats can be accommodated by changing the data stored in the database, e.g. to generate a new signature in response to a new or different packet format.
  • the signature can be used to directly control or determine processing for the data packet or handling. If desired, however, the signature can also be used to output other data such as using the signature as (all or part of) a key to a content-addressable memory (CAM) which outputs a pointer to an entry point in microcode.
  • CAM content-addressable memory
  • the database includes a plurality of registers, with each register being used for setting (or clearing) one or more bits of the signature word.
  • each register may define a word offset and/or bit field defining the bits of the packet to be compared, a data field defining the data to which the “masked” data from the packet is to be compared and an indication of which bit or bits in the signature word should be set (or cleared) as a result of the comparison.
  • storing new or modified data in the registers suffices to provide a new and unique signature word in response to a new or different packet format.
  • FIGS. 1A through 1C depict the various fields in data packets according to examples of three different packet formats
  • FIG. 1D illustrates an example of Ipv 4 format
  • FIG. 2 depicts a logic tree useable for distinguishing among three different packet formats
  • FIG. 3 depicts a set of registers with field indications thereon for storing a database useable in connection with the present invention.
  • FIG. 4 is a block diagram illustrating an example of using a plurality of registers for forming a signature word according to an embodiment of the present invention
  • FIG. 5 is a block diagram depicting components used in parsing and handling data packets according to an embodiment of the present invention.
  • FIG. 6 is a schematic block diagram of a comparator according to an embodiment of the present invention.
  • Packets arriving at a device may have any of a plurality of different packet formats, some examples of which are illustrated in FIGS. 1A through 1C.
  • the packet arrives in a format having several layers of encapsulation, such as a physical layer encapsulation, layer two protocol types and layer three protocol types.
  • the formats for packets arriving at a router or similar device are substantially random in the sense that it is generally impossible to reliably predict what will be the format of the next packet to arrive.
  • FIGS. 1A through 1C illustrate three different packet formats, numerous other packet formats are in use and others can be expected to be developed.
  • the present invention can be configured to operate with a plurality of, and preferably all of, the various packet formats.
  • the format for data packets arriving e.g. at a router are substantially random (i.e. substantially unpredictable) and new standards or formats are frequently introduced (and need to be handled by the parser). Such new or different formats may differ substantially from previous formats in a fashion which typically is not under the control of those providing packet parsers. Packets must be parsed at a rate substantially equal to the rate at which the packets arrive, yet data rates used in network or similar communication change frequently in a manner typically not under the control of those who provide packet parsers.
  • the packet When a packet arrives at a router or similar device, the packet may be handled differently by the router depending on such items as the source address (SA), destination address (DA), data type/length, packet total length, type of service (TOS), user priority and the like. Some or all of such information is contained in various fields of the data packet. However, the location of a particular field (i.e. a particular type of information) within a packet may vary among different packet formats. For example, when the format of FIG. 1D is encapsulated using the format of FIG. 1A, the IP DA, resides in bytes 30 through 33 (i.e. the position of IP DA in FIG. 1D, plus the 18 byte offset of FIG. 1 A); however when the format of FIG.
  • SA source address
  • DA destination address
  • TOS type of service
  • FIG. 1D is encapsulated using the format of FIG. 1C, the IP DA resides in bytes 38 through 41 (i.e. the position of IP DA in FIG. 1D, plus the 26 byte offset of FIG. 1 C).
  • FIGS. 1A through 1D Other differences among the location of various fields or types of information in various formats are illustrated in FIGS. 1A through 1D and the formats of various packets are generally known to those of skill in the part and/or defined by various standards such as IEEE 802.2 and 802.3 and the like.
  • the format of the packet must be determined. Although there may be some buffering capability in the router or similar device, in general, if it is desired for the packet throughput to match the data rate of the incoming data, the router must be able to parse any packet in a time frame no greater than the time between arrival of sequential packets (at the fastest data rate). It is not uncommon for data packets to arrive at a rate of about 150,000 packets per second, e.g. for a 100 megabit link, and the packet rate may be as high as about 1.5 million packets per second, for a 1 gigabit link, or more. Further, it is anticipated that even higher packet rates will be used in the future. Accordingly, the present invention can be configured to perform complete parsing of any packet sufficiently rapidly to keep up with the packet rates noted above, including anticipated increases in packet rates, i.e can parse packets substantially as fast as they arrive.
  • a network switch or router when handling the packet, will select, e.g., the output port to which the packet is provided depending, at least partially, on the destination address. Accordingly, before selecting which microcode to execute in connection with handling a given packet, a router must use information regarding the format of the packet such as whether the packet is the format of FIG. 1A, the format of FIG. 1C, or some other format, in order to know whether to use the data in bytes 30 - 33 (in the format of FIG. 1A) or bytes 38 - 41 (in the format of FIG. 1 C), or other fields in other formats, as the IP destination address. Other fields in the data packet are also used in connection with determining how a packet is to be handled, as will be understood by those of skill in the art.
  • FIG. 2 illustrates the series of decisions or comparisons that may be used in distinguishing among three different packet formats: (1) Ethernet V 2 IP TCP; (2) Ethernet V 2 IP UDP; (3) Ethernet V 2 IPX.
  • the logic tree involves a plurality of binary (yes/no) decisions or comparisons, typically each comparison involving testing whether a given bit field of the packet (possibly masked) is equal to (or in some cases less than or greater than) a predefined value.
  • the logic tree of FIG. 2 is somewhat simplified in the sense that it distinguishes among only three formats. More complex trees, (although generally still in the nature of that illustrated in FIG. 2) can be used for distinguishing among a larger variety of packet formats, as will be understood by those of skill in the art.
  • the comparisons are performed in a sequential fashion (reading left to right in the illustration of FIG. 2) and the outcome of a given comparison may determine what the next comparison or test is to be.
  • the dependency of a particular comparison or test on the outcome of the previous comparison means that, in this approach, tests are at least partly sequential.
  • the logic tree of FIG. 2 can be implemented in a number of fashions.
  • a logic tree in the nature of that depicted in FIG. 2 is implemented by executing microcode in a microprocessor.
  • a given branch or node of the logic tree of FIG. 2 can be implemented, using a microprocessor, by fetching the desired bit field for comparison, optionally masking to select certain bits, performing a “compare” with a pre-stored value fetched from memory and performing a “branch”, based on the result of the “compare” operation, to microcode which either performs the next test or outputs the format (if one has been determined).
  • Another manner of implementing the logic tree of in the nature of that illustrated in FIG. 2 is to use a state machine, e.g., in which branches are hard-coded.
  • the data packet (or portions thereof such as header or footer portions) may be temporarily stored e.g. in a register.
  • Each of (some or all of) the bits in such register can control a branch, e.g. based on a bit compare (such as comparing to, e.g., a hard-wired bit value), with the result of the comparison, possibly combined with results from other comparisons, being used to perform (or control the performance of) other state machine branches, with the process operating in a generally recursive fashion until the packet format has been determined.
  • a bit compare such as comparing to, e.g., a hard-wired bit value
  • the present invention involves using data which can be written or stored, e.g. in a plurality of registers, providing a type of database, which can be used, in combination, to create a preferably unique signature word identifying the packet format.
  • FIG. 3 illustrates one embodiment of a database useable in connection with the present invention.
  • the database is stored in a plurality of (in the illustrated embodiment, 64 ) registers organized in pairs.
  • the database contains information defining various comparisons to be made on different fields of the data packet.
  • FIG. 3 illustrates one embodiment of a database useable in connection with the present invention.
  • the database is stored in a plurality of (in the illustrated embodiment, 64 ) registers organized in pairs.
  • the database contains information defining various comparisons to be made on different fields of the data packet.
  • each pair of registers includes a word offset 312 a,b,c for defining which word of the data packet contains the field to be used for a given comparison, a bit offset 314 a,b,c defining (alone or combined with other comparison results) which bit of the signature is to be set in response to the comparison result, a parsing mask 316 a,b,c to select certain bits from the selected word of the data packet for comparison, and parsing data 318 a,b,c containing the data bits to which the selected bits from the data packet are to be compared.
  • Table I provides one example of field definitions for a data base, such as that as illustrated in FIG. 3, according to one embodiment of the invention.
  • the tables below and other examples provided herein are illustrative in nature and are intended as examples and not necessarily as limitations on the scope of the invention.
  • Other formats and fields for databases can also be used as will be apparent to those of skill in the art after understanding the present invention.
  • Table II provides values for six entries in a database similar to the database of FIG. 3 which, if used would result in providing a unique signature word for each of the three types of packets distinguished in the illustration of FIG. 2 . (In this example, comparison is 16 bits at a time)
  • Ethernet V2 IP TCP ⁇ > 0000_0000_0000_0000_0000_0001_1010 2.
  • Ethernet V2 IP UDP ⁇ > 0000_0000_0000_0000_0010_1010 3.
  • Ethernet V2 IPX ⁇ > 0000_0000_0000_0000_0000_0100
  • Table III shows the values for three signature words resulting from parsing each of the three types of packet formats of FIG. 2 using a database having entries as illustrated in Table II.
  • the signature word is 32 bits.
  • larger or smaller signature words can be used as will be understood by those of skill in the art.
  • the signature word corresponding to the three different formats have respectively, different values and thus can be used for distinguishing among the three different formats.
  • Tables II and III are somewhat simplified in that they are configured for distinguishing among only three different formats.
  • the present invention can be used to distinguish among a large number of different formats e.g. by providing additional entries in the database for performing additional comparisons and setting or clearing other bits in the signature word, as will be understood by those of skill in the art after understanding the present disclosure.
  • FIG. 4 is a block diagram schematically depicting a manner in which different entries in the filtering database 412 control comparisons, each of which (alone or combined with other comparisons) results in setting or clearing (e.g in accordance with stored information such as the “action” field in the example of Table I) particular bits of a signature word 416 .
  • FIG. 4 illustrates a line connection between each entry (i.e. each pair of registers) in the database 412 and a particular bit of the signature word 416 , as noted above, the database itself 412 contains information (e.g. bit offsets 314 a,b,c ) which determines the bit to be set or cleared as a result of the comparison.
  • the result of the comparison (alone or combined with the result of another comparison) will be routed to a particular bit using the bit offset 314 a,b,c as a bit write address for the signature word 416 .
  • the OR may be performed by hardwired logic such as an OR gate 422 or can be selected (such as by routing the results of two or more comparisons to a selected type of logic gate under control of another piece of information, e.g. in the “operation” field in the illustrative example above.).
  • the data stored in the filtering database 412 can be used for controlling bit comparisons in a number of fashions.
  • each database entry is coupled to the word offset, mask, and data inputs of a comparator 612 .
  • FIG. 6 illustrates the comparator 612 in schematic form (such as showing a controlled mechanical switch for selecting word or bit offsets) those of skill in the part will understand how to provide a comparator in a practical sense for performing the functions illustrated schematically in FIG. 6 .
  • the comparator 612 will use the word offset information 614 to fetch 615 or use a selected word from the data packet 616 , will apply the received mask data 618 to a masking operation 622 to select a particular bit or bits from such word, and will then perform a comparison of the masked packet data 624 with the data received in the data input 626 .
  • the comparator 623 may be configured to provide an “equals” comparison (e.g.
  • outputting a “one” if there is an exact match between the masked data from the packet and the input data may perform a “greater than” or “less than”comparison (outputting a “zero” unless the masked packet data is greater than or less than, respectively, the input data) or may be configured to perform any of these different types of comparisons (e.g. in response to a comparison control signal 628 which may also be stored in the database.
  • the result bit 632 from the comparison is routed 634 to the proper bit of the signature word 636 under control of a bit offset 638 stored in the database 610 .
  • each of pair of registers 608 a,b,n in the database 610 can be coupled to a separate comparator 612 (in the fashion illustrated in FIG. 6) so that some or all of the comparisons can be performed substantially simultaneously and some or all of the bits of the signature word can be set or cleared substantially simultaneously, if desired.
  • a separate comparator 612 in the fashion illustrated in FIG. 6
  • the signature word can be used in a number of different fashions. For example, it is possible (although not necessarily practical, in many embodiments) to construct the signature word in a fashion such that the signature word itself operates as a pointer to various microcode (for execution by a microprocessor), for handling the particular type or format of the data packet. This approach, however, places constraints on where microcode entry points for different packet handling procedures can be stored.
  • Another way of using the signature is to match a (possibly masked) signature with a set of predetermined signatures, e.g. using a look-up table, and obtain associated data (such as an identifier, an “illegal data” indicator, a “send to CPU” indicator, a pointer, or an index to a set of commands).
  • a (possibly masked) signature with a set of predetermined signatures, e.g. using a look-up table, and obtain associated data (such as an identifier, an “illegal data” indicator, a “send to CPU” indicator, a pointer, or an index to a set of commands).
  • packets 410 of the incoming datastream “snooped” 417 for providing packet fields to the database 412 and generating the signature word 416 .
  • the signature word 416 is output as a key or lookup argument to a content addressable memory (CAM) 512 .
  • the CAM 512 is a “ternary” CAM, permitting a key, such as the signature word 416 , to be masked, if desired, before addressing the CAM.
  • a plurality of pointers are stored in the content addressable memory 512 in such a fashion that, in response to a signature 416 identifying a particular type of or format of packet 416 , the CAM 512 outputs a pointer 514 which points to an appropriate entry point in stored microcode or commands (such as microcode stored in an EEPROM 516 ).
  • the microcode beginning with the pointed-to entry point, is then executed by a microprocessor 518 which operates on the packet 416 and handles the packet in an appropriate manner according to the information stored in the now-known format of the packet.
  • the commands which are executed would extract fields of interest from the data packet, depending on the format of the packet.
  • IPSA and IPDA need to be extracted from the packet to perform a lookup.
  • the executed commands can include “extract byte 30 - 37 as lookup key”. It is noted that, although in this and other embodiments, a microprocessor is used for packet handling, it is not necessary to use the microprocessor for the parsing of the packet.
  • the present invention provides for accommodating new or different types of packet formats in a packet parser by storing new data or information e.g. in a database and substantially without the need (or with reduced need) for creating or installing new hardware. Accordingly, it is no longer necessary, at least in some embodiments of the present invention, to redesign and/or refabricate and a new ASIC or other hardware in order to accommodate a new or different packet format.
  • the present invention is highly flexible in its method of parsing a packet and can accommodate wide variety of different or new packet formats.
  • the present invention can be substantially or completely software-controlled in terms of identifying new or different packet types.
  • a CAM including a ternary CAM
  • the CAM of FIG. 5 can be used for the purpose described herein without the need to incur additional hardware costs.
  • the present invention can be implemented without the need for a processor or an embedded micro-coded engine for parsing data packets.
  • the data base has been described as being stored in a plurality of registers, it is also possible to store some or all of the database information in other storage devices such as a programmable logic array (PLA), programmable read only memory (PROM) or the like.
  • PPA programmable logic array
  • PROM programmable read only memory
  • the database has been described as including, for each database entry, a field which determines the particular bit of the signature which is to be set or cleared as a result of the comparison, it is also possible to provide this information in another fashion such as by storage in a separate database, and/or by hardwiring. In general it is possible to use some features of the present invention without using others.
  • the database as described above for (rewriteably) storing certain parsing information such as the data against which fields are to be tested, while providing other information in a different fashion such as being hardwired.
  • certain parsing information such as the data against which fields are to be tested
  • other information in a different fashion such as being hardwired.
  • hardwired logic it would be possible to use hardwired logic to select the bits from the data packet for each comparison but use the database for (programmably) storing the data to which those bits are to be compared and/or the location of the bits in the signature word to be reset or cleared as a result of such comparisons.
  • the present invention in various embodiments, includes components, methods, processes, systems and/or apparatus substantially as depicted and described herein, including various embodiments, subcombinations, and subsets thereof. Those of skill in the art will understand how to make and use the present invention after understanding the present disclosure.
  • the present invention in various embodiments, includes providing devices and processes in the absence of items not depicted and/or described herein or in various embodiments hereof, including in the absence of such items as may have been used in previous devices or processes, e.g. for improving performance, achieving ease and or reducing cost of implementation.

Abstract

A data packet parser, for determining packet format, is substantially software controlled, to readily accommodate new or different formats, without the need for using a microprocessor for parsing. Comparisons are performed under the control of data stored in a database. By storing new or different data in the database, new or different packet formats can accommodated without the need for making hardware changes. In one embodiment, comparisons performed on various fields of the data packet result in setting or clearing bits of a signature word which identifies the packet format. The signature word can be used directly or indirectly such as forming the input argument of a ternary CAM, to provide a pointer to microcode which appropriately handles the data packet in the identified format.

Description

The present invention relates to an apparatus and method for parsing data packets having different formats and in particular to parsing which is programmable, e.g. to accommodate new or different formats, but which can be provided without the need for using a microprocessor for parsing.
BACKGROUND INFORMATION
A number of electronic devices can receive data packets which may be in any of a plurality of different formats, which may not be known in advance. Examples include network routers, gateways, bridges, hubs and the like. Typically, information is included in the packets which is useful in determining how to handle or process the packets. For example, packets may include information regarding the destination of the packet, the size of the packet (or various fields therein) and the like. There are, however, a plurality of different formats for data packets and the location of information within various data packets may differ in the various formats. For example, one format may provide destination information in bytes 30 through 33 of a packet while another may provide destination information in bytes 38 through 41. Accordingly, in order to properly handle a data packet, it is typically necessary to determine the format of the data packet. The process of determining the format, and using such determination to identify the location of various data (e.g. to facilitate handling of the packet), is known as parsing the packet.
The parsing of network data packets presents certain challenges which are believed substantially unique compared to other types of parsing. For example, typically the time available for parsing a packet is driven by the rate at which packets arrive, i.e. a given packet typically must be fully parsed before the next packet arrives. In a typical situation it is substantially infeasible to predict the format of the next packet, i.e. packets may arrive in substantially random formats. In many situations, a given type of data, although positioned in different locations for different formats, nevertheless may be used in substantially the same way for different formats. For example, although destination information may be located at different places for differently formatted packets, the destination information is used in substantially the same way for handling many, if not all, of the differently-formatted packets.
Various devices and procedures have been used for packet parsing. In one approach, a microprocessor, or an embedded microcoded engine, executes microcode which performs a plurality of (typically sequential) tests or comparisons on various data and/or fields of the packet to determine the packet format. An advantageous aspect of this approach is that the system can be configured to accommodate new packet formats by revising the microcode, i.e. substantially without the need for redesigning hardware (such as without the need for redesigning the microprocessor). Unfortunately, this approach can be relatively expensive. If a microprocessor is used for parsing packets, the cost of the microprocessor can undesirably increase the cost of the network router or other apparatus. If the microprocessor is also being used for other purposes, there can still be substantial expense involved because it is necessary to provide a processor which has a sufficiently high performance that it can perform both parsing functions and other functions and can perform such functions quickly enough to accommodate the data rates or data speeds of the incoming packets. Thus, providing a microprocessor for packet parsing functions can involve providing a processor which has higher performance (and typically higher cost) than would otherwise be necessary. Accordingly, it would be useful to provide a packet parser which can be implemented in an economic fashion preferably without the need to use a microprocessor or an embedded microcoded engine for packet parsing functions.
Another approach for handling data packets has been using partly or fully hardwired logic. For example, hardwired logic may be configured to test a first predefined field or bit of each incoming packet and, depending on the result of the comparison, branching to a next comparison for a second field or bit of the packet. This procedure is repeated recursively until the packet is parsed. Each test, in this configuration, is performed by hardwired logic and, accordingly, one disadvantageous aspect of such an approach is that new or different formats cannot be accommodated with a change in programming or software. Rather, when the hardwired logic is implemented, e.g., in an application specific integrated circuit (ASIC), a new or different format for packets requires redesigning the hardwired logic and generating a new ASIC, typically at substantial expense. Typically, redesigning and refabricating an ASIC requires months of time and relatively high expense in nonrecurring engineering (NRE) charges. Moreover, because of the nature of the “tree” logic typically used for hardwired parsing, there is no guarantee that a new or different format can be accommodated by a minor change in the hardwired logic. Thus, accommodating a new or changed format may often involve substantial redesign of the logic tree, possibly at relatively high expense. Another generally disadvantageous aspect of hardwired parsers is that in-service parsers are not easily upgraded e.g. to accommodate new or different formats. Typically, the owner of a router or similar device with hardwired parsers must acquire, and have installed, new hardware in order to accommodate new or changed packet formats. There may be substantial network down time involved in such hardware installation. Accordingly it would be desirable to provide a packet parser which can accommodate new or different packet formats by way of upgrading in-service routers or similar devices, without requiring the installation of new hardware.
In general, it would be useful to provide a data packet parser which can accommodate new or changed data packet formats without the need for changing or redesigning hardwired logic or other hardware, preferably by merely making software or programming changes and preferably in a way such that a new or changed packet format can be accommodated without the need for redesigning an entire logic tree.
SUMMARY OF THE INVENTION
The present invention provides a method and apparatus for parsing data packets without the need for using a microprocessor to achieve such parsing, yet which can accommodate new or different packet formats without the need for changing hardwired logic or other circuitry or hardware (such as by changing programming or software). According to one embodiment, a database is stored, e.g. such as storing in a plurality of registers, which is used in providing a signature word for each packet, with the signature words being indicative of particular packet formats. New or different formats can be accommodated by changing the data stored in the database, e.g. to generate a new signature in response to a new or different packet format.
The signature can be used to directly control or determine processing for the data packet or handling. If desired, however, the signature can also be used to output other data such as using the signature as (all or part of) a key to a content-addressable memory (CAM) which outputs a pointer to an entry point in microcode. In this way, it is possible to avoid the need for reconfiguring hardwired logic or other hardware in order to accommodate new or different packet formats, but without needing to provide a microprocessor for packet parsing purposes.
In one embodiment, the database includes a plurality of registers, with each register being used for setting (or clearing) one or more bits of the signature word. For example, each register may define a word offset and/or bit field defining the bits of the packet to be compared, a data field defining the data to which the “masked” data from the packet is to be compared and an indication of which bit or bits in the signature word should be set (or cleared) as a result of the comparison. In this way, storing new or modified data in the registers suffices to provide a new and unique signature word in response to a new or different packet format.
BRIEF DESCRIPTION OF THE DRAWINGS
FIGS. 1A through 1C depict the various fields in data packets according to examples of three different packet formats;
FIG. 1D illustrates an example of Ipv4 format;
FIG. 2 depicts a logic tree useable for distinguishing among three different packet formats;
FIG. 3 depicts a set of registers with field indications thereon for storing a database useable in connection with the present invention.
FIG. 4 is a block diagram illustrating an example of using a plurality of registers for forming a signature word according to an embodiment of the present invention;
FIG. 5 is a block diagram depicting components used in parsing and handling data packets according to an embodiment of the present invention; and
FIG. 6 is a schematic block diagram of a comparator according to an embodiment of the present invention.
DETAILED DESCRIPTION
Packets arriving at a device such as a network router and the like, may have any of a plurality of different packet formats, some examples of which are illustrated in FIGS. 1A through 1C. In a typical situation, the packet arrives in a format having several layers of encapsulation, such as a physical layer encapsulation, layer two protocol types and layer three protocol types. Generally the formats for packets arriving at a router or similar device are substantially random in the sense that it is generally impossible to reliably predict what will be the format of the next packet to arrive. Although FIGS. 1A through 1C illustrate three different packet formats, numerous other packet formats are in use and others can be expected to be developed. The present invention can be configured to operate with a plurality of, and preferably all of, the various packet formats.
In general, there are believed to be substantial differences between requirements for parsing network data packets and other types of parsing. The format for data packets arriving e.g. at a router, are substantially random (i.e. substantially unpredictable) and new standards or formats are frequently introduced (and need to be handled by the parser). Such new or different formats may differ substantially from previous formats in a fashion which typically is not under the control of those providing packet parsers. Packets must be parsed at a rate substantially equal to the rate at which the packets arrive, yet data rates used in network or similar communication change frequently in a manner typically not under the control of those who provide packet parsers.
When a packet arrives at a router or similar device, the packet may be handled differently by the router depending on such items as the source address (SA), destination address (DA), data type/length, packet total length, type of service (TOS), user priority and the like. Some or all of such information is contained in various fields of the data packet. However, the location of a particular field (i.e. a particular type of information) within a packet may vary among different packet formats. For example, when the format of FIG. 1D is encapsulated using the format of FIG. 1A, the IP DA, resides in bytes 30 through 33 (i.e. the position of IP DA in FIG. 1D, plus the 18 byte offset of FIG. 1A); however when the format of FIG. 1D is encapsulated using the format of FIG. 1C, the IP DA resides in bytes 38 through 41 (i.e. the position of IP DA in FIG. 1D, plus the 26 byte offset of FIG. 1C). Other differences among the location of various fields or types of information in various formats are illustrated in FIGS. 1A through 1D and the formats of various packets are generally known to those of skill in the part and/or defined by various standards such as IEEE 802.2 and 802.3 and the like.
Accordingly, in order for the router or similar device to handle or process a packet, the format of the packet must be determined. Although there may be some buffering capability in the router or similar device, in general, if it is desired for the packet throughput to match the data rate of the incoming data, the router must be able to parse any packet in a time frame no greater than the time between arrival of sequential packets (at the fastest data rate). It is not uncommon for data packets to arrive at a rate of about 150,000 packets per second, e.g. for a 100 megabit link, and the packet rate may be as high as about 1.5 million packets per second, for a 1 gigabit link, or more. Further, it is anticipated that even higher packet rates will be used in the future. Accordingly, the present invention can be configured to perform complete parsing of any packet sufficiently rapidly to keep up with the packet rates noted above, including anticipated increases in packet rates, i.e can parse packets substantially as fast as they arrive.
As one example, a network switch or router (or similar device), when handling the packet, will select, e.g., the output port to which the packet is provided depending, at least partially, on the destination address. Accordingly, before selecting which microcode to execute in connection with handling a given packet, a router must use information regarding the format of the packet such as whether the packet is the format of FIG. 1A, the format of FIG. 1C, or some other format, in order to know whether to use the data in bytes 30-33 (in the format of FIG. 1A) or bytes 38-41 (in the format of FIG. 1C), or other fields in other formats, as the IP destination address. Other fields in the data packet are also used in connection with determining how a packet is to be handled, as will be understood by those of skill in the art.
Previous approaches to packet parsing have typically involved a multi-step, typically sequential, analysis or decision process. FIG. 2 illustrates the series of decisions or comparisons that may be used in distinguishing among three different packet formats: (1) Ethernet V2 IP TCP; (2) Ethernet V2 IP UDP; (3) Ethernet V2 IPX. In the illustration of FIG. 2, the logic tree involves a plurality of binary (yes/no) decisions or comparisons, typically each comparison involving testing whether a given bit field of the packet (possibly masked) is equal to (or in some cases less than or greater than) a predefined value. The logic tree of FIG. 2 is somewhat simplified in the sense that it distinguishes among only three formats. More complex trees, (although generally still in the nature of that illustrated in FIG. 2) can be used for distinguishing among a larger variety of packet formats, as will be understood by those of skill in the art.
In the logic tree of FIG. 2, the comparisons are performed in a sequential fashion (reading left to right in the illustration of FIG. 2) and the outcome of a given comparison may determine what the next comparison or test is to be. The dependency of a particular comparison or test on the outcome of the previous comparison means that, in this approach, tests are at least partly sequential.
The logic tree of FIG. 2 can be implemented in a number of fashions. In one previous approach, a logic tree in the nature of that depicted in FIG. 2 is implemented by executing microcode in a microprocessor. For example, a given branch or node of the logic tree of FIG. 2 can be implemented, using a microprocessor, by fetching the desired bit field for comparison, optionally masking to select certain bits, performing a “compare” with a pre-stored value fetched from memory and performing a “branch”, based on the result of the “compare” operation, to microcode which either performs the next test or outputs the format (if one has been determined).
Another manner of implementing the logic tree of in the nature of that illustrated in FIG. 2 is to use a state machine, e.g., in which branches are hard-coded. For example, the data packet (or portions thereof such as header or footer portions) may be temporarily stored e.g. in a register. Each of (some or all of) the bits in such register can control a branch, e.g. based on a bit compare (such as comparing to, e.g., a hard-wired bit value), with the result of the comparison, possibly combined with results from other comparisons, being used to perform (or control the performance of) other state machine branches, with the process operating in a generally recursive fashion until the packet format has been determined. Those of skill in the art will understand how to provide a state machine with hard-coded branching.
The present invention involves using data which can be written or stored, e.g. in a plurality of registers, providing a type of database, which can be used, in combination, to create a preferably unique signature word identifying the packet format.
FIG. 3 illustrates one embodiment of a database useable in connection with the present invention. In this embodiment, the database is stored in a plurality of (in the illustrated embodiment, 64) registers organized in pairs. The database contains information defining various comparisons to be made on different fields of the data packet. In the embodiment of FIG. 3, each pair of registers includes a word offset 312 a,b,c for defining which word of the data packet contains the field to be used for a given comparison, a bit offset 314 a,b,c defining (alone or combined with other comparison results) which bit of the signature is to be set in response to the comparison result, a parsing mask 316 a,b,c to select certain bits from the selected word of the data packet for comparison, and parsing data 318 a,b,c containing the data bits to which the selected bits from the data packet are to be compared.
Table I provides one example of field definitions for a data base, such as that as illustrated in FIG. 3, according to one embodiment of the invention. The tables below and other examples provided herein are illustrative in nature and are intended as examples and not necessarily as limitations on the scope of the invention. Other formats and fields for databases can also be used as will be apparent to those of skill in the art after understanding the present invention.
TABLE I
Offset Field Name Definition
0, 2, 4, . . . wordOffset Word offset for the word to be
compared from packet header
(0 to maximum size of header)
bitOffset Bit position of the bit to be set in the
packetSignature after a match.
Multiple bits pointing to the same
location result in an ORed operation.
(0 to maximum size of packet)
operation Identifies the compare operation.
It can be, e.g., “equal”, “not
equal”, “greater than” or ”less than
Example encoding:
00: equal
01: not equal
10: greater than
11: less than
action Identifies that the corresponding bit
should be set or reset if the
compare result is true.
Example encoding:
0: reset
1: set
1, 3, 5, . . . parsingMask The mask to be applied before compare.
Example encoding:
1: The bit is compared
0: The bit is masked (not compared)
parsingData Data to be matched.
As a somewhat simplified example illustrating one implementation of the present invention, Table II provides values for six entries in a database similar to the database of FIG. 3 which, if used would result in providing a unique signature word for each of the three types of packets distinguished in the illustration of FIG. 2. (In this example, comparison is 16 bits at a time)
TABLE III
1. Ethernet V2 IP TCP −> 0000_0000_0000_0000_0000_0000_0001_1010
2. Ethernet V2 IP UDP −> 0000_0000_0000_0000_0000_0000_0010_1010
3. Ethernet V2 IPX −> 0000_0000_0000_0000_0000_0000_0000_0100
Table III shows the values for three signature words resulting from parsing each of the three types of packet formats of FIG. 2 using a database having entries as illustrated in Table II. In the illustrative example of Table III, the signature word is 32 bits. However, larger or smaller signature words can be used as will be understood by those of skill in the art. As can be seen from Table III, the signature word corresponding to the three different formats have respectively, different values and thus can be used for distinguishing among the three different formats.
TABLE II
word parsing- parsing-
entry Offset Mask Data operation action bitOffset
1 8 0xFE00 0x0600 11 1 0
2 8 0xFFFF 0x0800 00 1 1
3 8 0xFFFF 0x8137 00 1 2
4 8 0xFFFF 0x8138 00 1 2
5 9 0xFF00 0x4500 00 1 3
6 13 0x00FF 0x0006 00 1 4
7 13 0x00FF 0x0011 00 1 5
The illustrations of Tables II and III are somewhat simplified in that they are configured for distinguishing among only three different formats. However, the present invention can be used to distinguish among a large number of different formats e.g. by providing additional entries in the database for performing additional comparisons and setting or clearing other bits in the signature word, as will be understood by those of skill in the art after understanding the present disclosure.
FIG. 4 is a block diagram schematically depicting a manner in which different entries in the filtering database 412 control comparisons, each of which (alone or combined with other comparisons) results in setting or clearing (e.g in accordance with stored information such as the “action” field in the example of Table I) particular bits of a signature word 416. Although, for clarity, FIG. 4 illustrates a line connection between each entry (i.e. each pair of registers) in the database 412 and a particular bit of the signature word 416, as noted above, the database itself 412 contains information (e.g. bit offsets 314 a,b,c) which determines the bit to be set or cleared as a result of the comparison. Accordingly, in practice, the result of the comparison (alone or combined with the result of another comparison) will be routed to a particular bit using the bit offset 314 a,b,c as a bit write address for the signature word 416. In some embodiments, it is desired to provide the ability for a given bit of the signature word, (e.g. bit 418 a in the illustration of FIG. 4) to be set or cleared as a result of two or more different comparisons. As shown in FIG. 4, this can be implemented by performing an OR operation (or other operation such as AND, NOT, NOR similar logical operations). The OR (or other combination) may be performed by hardwired logic such as an OR gate 422 or can be selected (such as by routing the results of two or more comparisons to a selected type of logic gate under control of another piece of information, e.g. in the “operation” field in the illustrative example above.).
The data stored in the filtering database 412 can be used for controlling bit comparisons in a number of fashions. Preferably, as illustrated in FIG. 6, each database entry is coupled to the word offset, mask, and data inputs of a comparator 612. Although FIG. 6 illustrates the comparator 612 in schematic form (such as showing a controlled mechanical switch for selecting word or bit offsets) those of skill in the part will understand how to provide a comparator in a practical sense for performing the functions illustrated schematically in FIG. 6. The comparator 612 will use the word offset information 614 to fetch 615 or use a selected word from the data packet 616, will apply the received mask data 618 to a masking operation 622 to select a particular bit or bits from such word, and will then perform a comparison of the masked packet data 624 with the data received in the data input 626. The comparator 623 may be configured to provide an “equals” comparison (e.g. outputting a “one” if there is an exact match between the masked data from the packet and the input data), may perform a “greater than” or “less than”comparison (outputting a “zero” unless the masked packet data is greater than or less than, respectively, the input data) or may be configured to perform any of these different types of comparisons (e.g. in response to a comparison control signal 628 which may also be stored in the database.
The result bit 632 from the comparison is routed 634 to the proper bit of the signature word 636 under control of a bit offset 638 stored in the database 610.
Although it is possible to configure the creation of the signature word so that it operates in a stepwise fashion (such that comparisons are performed one after another without two or more comparisons being performed simultaneously) it is generally preferred, at present, to perform some or all of the comparisons substantially simultaneously. For example, each of pair of registers 608 a,b,n in the database 610 can be coupled to a separate comparator 612 (in the fashion illustrated in FIG. 6) so that some or all of the comparisons can be performed substantially simultaneously and some or all of the bits of the signature word can be set or cleared substantially simultaneously, if desired. In this fashion, it is possible to provide relatively rapid parsing of a data packet, particularly compared with approaches which involve sequential performance of multiple comparisons.
After the signature word identifying the packet format has been formed, the signature word can be used in a number of different fashions. For example, it is possible (although not necessarily practical, in many embodiments) to construct the signature word in a fashion such that the signature word itself operates as a pointer to various microcode (for execution by a microprocessor), for handling the particular type or format of the data packet. This approach, however, places constraints on where microcode entry points for different packet handling procedures can be stored.
Another way of using the signature is to match a (possibly masked) signature with a set of predetermined signatures, e.g. using a look-up table, and obtain associated data (such as an identifier, an “illegal data” indicator, a “send to CPU” indicator, a pointer, or an index to a set of commands).
In another approach, illustrated in FIG. 5, packets 410 of the incoming datastream “snooped” 417 for providing packet fields to the database 412 and generating the signature word 416. The signature word 416 is output as a key or lookup argument to a content addressable memory (CAM) 512. In one embodiment, the CAM 512 is a “ternary” CAM, permitting a key, such as the signature word 416, to be masked, if desired, before addressing the CAM. A plurality of pointers are stored in the content addressable memory 512 in such a fashion that, in response to a signature 416 identifying a particular type of or format of packet 416, the CAM 512 outputs a pointer 514 which points to an appropriate entry point in stored microcode or commands (such as microcode stored in an EEPROM 516). The microcode, beginning with the pointed-to entry point, is then executed by a microprocessor 518 which operates on the packet 416 and handles the packet in an appropriate manner according to the information stored in the now-known format of the packet. In one embodiment, the commands which are executed would extract fields of interest from the data packet, depending on the format of the packet. For example, for IP routing lookup, IPSA and IPDA need to be extracted from the packet to perform a lookup. Once the packet is identified as, e.g., an Ethernet V2 encapsulated IP V4 packet, the executed commands can include “extract byte 30-37 as lookup key”. It is noted that, although in this and other embodiments, a microprocessor is used for packet handling, it is not necessary to use the microprocessor for the parsing of the packet.
In view of the above description a number of advantages that present invention can be seen. The present invention provides for accommodating new or different types of packet formats in a packet parser by storing new data or information e.g. in a database and substantially without the need (or with reduced need) for creating or installing new hardware. Accordingly, it is no longer necessary, at least in some embodiments of the present invention, to redesign and/or refabricate and a new ASIC or other hardware in order to accommodate a new or different packet format. The present invention is highly flexible in its method of parsing a packet and can accommodate wide variety of different or new packet formats. The present invention can be substantially or completely software-controlled in terms of identifying new or different packet types. Although many types of devices might be used for producing a pointer on the basis of a signature, a CAM, including a ternary CAM, is often included as part of a router or similar system and, in such devices, the CAM of FIG. 5 can be used for the purpose described herein without the need to incur additional hardware costs. The present invention can be implemented without the need for a processor or an embedded micro-coded engine for parsing data packets.
A number of variations of modifications of the invention can be used. Although the data base has been described as being stored in a plurality of registers, it is also possible to store some or all of the database information in other storage devices such as a programmable logic array (PLA), programmable read only memory (PROM) or the like. Although the database has been described as including, for each database entry, a field which determines the particular bit of the signature which is to be set or cleared as a result of the comparison, it is also possible to provide this information in another fashion such as by storage in a separate database, and/or by hardwiring. In general it is possible to use some features of the present invention without using others. For example, it is possible to provide the database as described above for (rewriteably) storing certain parsing information such as the data against which fields are to be tested, while providing other information in a different fashion such as being hardwired. For example, although not currently believed to be a preferred approach, it would be possible to use hardwired logic to select the bits from the data packet for each comparison but use the database for (programmably) storing the data to which those bits are to be compared and/or the location of the bits in the signature word to be reset or cleared as a result of such comparisons.
The present invention, in various embodiments, includes components, methods, processes, systems and/or apparatus substantially as depicted and described herein, including various embodiments, subcombinations, and subsets thereof. Those of skill in the art will understand how to make and use the present invention after understanding the present disclosure. The present invention, in various embodiments, includes providing devices and processes in the absence of items not depicted and/or described herein or in various embodiments hereof, including in the absence of such items as may have been used in previous devices or processes, e.g. for improving performance, achieving ease and or reducing cost of implementation.
The foregoing discussion of the invention has been presented for purposes of illustration and description. The foregoing is not intended to limit the invention to the form or forms disclosed herein. Although the description of the invention has included description of one or more embodiments and certain variations and modifications, other variations and modifications are within the scope of the invention, e.g. as may be within the skill and knowledge of those in the art, after understanding the present disclosure. It is intended to obtain rights which include alternative embodiments to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangable and/or equivalent structures, functions, ranges or steps are disclosed herein, and without intending to publicly dedicate any patentable subject matter.

Claims (44)

What is claimed is:
1. Apparatus for facilitating parsing of a network data packet comprising:
a memory device for storing a plurality of database entries,
at least a first comparator which is controlled, at least partially in response to data from one or more of said database entries, to perform comparison of at least one of the plurality of database entries with at least a portion and to output a first comparison result, of said data packet said first comparison result forming at least a first part of a signature word at least partially identifying a format of said data packet.
2. Apparatus, as claimed in claim 1, wherein said memory device comprises a plurality of registers.
3. Apparatus, as claimed in claim 1, wherein said comparator compares said portion of said data packet to data obtained from said database.
4. Apparatus, as claimed in claim 1, wherein said comparison result is used for setting or clearing a bit location of said signature word and wherein said bit location is selected using data from said database.
5. Apparatus, as claimed in claim 1, wherein said portion of said data packet is selected using data from said database.
6. Apparatus, as claimed in claim 1 wherein said comparator includes masking circuitry for masking said portion of said data packet, using mask data obtained from said database.
7. Apparatus, as claimed in claim 1, further comprising a second comparator which outputs a second comparison result used for forming at least a second part of said signature word.
8. Apparatus, as claimed in claim 1, further comprising a second comparator which outputs a second comparison result for combination with said first comparison result for forming said first part of said signature word.
9. Apparatus, as claimed in claim 1, further comprising a content-addressable memory (CAM) configured to receive said signature word and output a pointer to a microcode entry point.
10. Apparatus, as claimed in claim 1 further comprising a look-up table configured to output associated data in response to said signature word.
11. A method for identifying a format of a network data packet comprising:
storing a plurality of comparison control data in a database;
comparing, using a comparator, at least a first portion of said data packet with parsing data, said comparing including outputting at least a first comparison result, wherein said comparing is at least partly controlled using at least first control data from said database;
forming at least a first portion of a signature word, the at least a first portion of a signature word including said first comparison result.
12. A method, as claimed in claim 11, wherein said step of storing comprises storing in at least a first of a plurality of registers.
13. A method, as claimed in claim 11, further comprising selecting said first portion of said data packet in response to data from said database.
14. A method, as claimed in claim 11, further comprising masking said first portion of said data packet with mask data from said database.
15. A method, as claimed in claim 11, wherein at least a portion of said parsing data is obtained from said database.
16. A method, as claimed in claim 11, further comprising selecting said first portion of said signature word in response to data from said database.
17. A method, as claimed in claim 11, wherein said comparing is selected from the group consisting of a less-than comparison, an equals comparison and a greater-than comparison.
18. A method, as claimed in claim 11, wherein a type of comparison is performed in response to data from said database.
19. A method, as claimed in claim 11, further comprising comparing at least a second portion of said data packet with parsing data and outputting at least a second comparison result.
20. A method as claimed in claim 19 further comprising combining said second comparison result with said first comparison result before said step of forming said first portion of said signature word.
21. A method, as claimed in claim 20, wherein said step of combining said second comparison result with said first comparison result includes performing an OR operation.
22. A method, as claimed in claim 19 further comprising forming a second portion of said signature word, different from said first portion, using said second comparison result.
23. A method, as claimed in claim 11, further comprising selecting one of a plurality of packet handling procedures for handling said packet, wherein said selecting is performed in response to said signature word.
24. A method, as claimed in claim 11, further comprising selecting a microcode entry point at least partially in response to said signature word.
25. A method, as claimed in claim 11 further comprising providing a content-addressable memory (CAM) and outputting a microcode pointer from said CAM in response to said signature word.
26. A method, as claimed in claim 11, further comprising storing new data in said database facilitating the handling of a different packet format.
27. Apparatus for identifying a format of a network data packet comprising:
means for storing a plurality of comparison control data;
means for comparing at least a first portion of said data packet with parsing data, and outputting at least a first comparison result, wherein said means for comparing is at least partly controlled using at least first control data from said means for storing;
means for forming at least a first portion of a signature word, the at least a first portion of a signature word including said first comparison result.
28. Apparatus, as claimed in claim 27, wherein said means for storing comprises a plurality of registers.
29. Apparatus, as claimed in claim 27, further comprising means for selecting said first portion of said data packet in response to data from said means for storing.
30. Apparatus, as claimed in claim 27, further comprising means for masking said first portion of said data packet with mask data from said means for storing.
31. Apparatus, as claimed in claim 27, wherein at least a portion of said parsing data is obtained from said means for storing.
32. Apparatus, as claimed in claim 27, further comprising means for selecting said first portion of said signature word in response to data from said means for storing.
33. Apparatus, as claimed in claim 27, further comprising means for selecting a type of comparison in response to data from said means for storing.
34. Apparatus, as claimed in claim 27, further comprising second means for comparing at least a second portion of said data packet with parsing data and outputting at least a second comparison result.
35. Apparatus as claimed in claim 34 further comprising means for combining said second comparison result with said first comparison result.
36. Apparatus, as claimed in claim 35, wherein said means for combining said second comparison result with said first comparison result includes an OR gate.
37. Apparatus, as claimed in claim 34 further comprising means for forming a second portion of said signature word, different from said first portion, using said second comparison result.
38. Apparatus, as claimed in claim 27, further comprising means for selecting one of a plurality of packet handling procedures for handling said packet, in response to said signature word.
39. Apparatus, as claimed in claim 27, further comprising means for selecting a microcode entry point at least partially in response to said signature word.
40. Apparatus, as claimed in claim 27 further comprising a content-addressable memory (CAM) configured to output a microcode pointer from said CAM in response to said signature word.
41. A method for handling a network data packet having a first format, comprising:
storing, in at least a first of plurality of registers, a plurality of comparison control data, forming a database;
selecting a first portion of said data packet in response to data from said database;
masking said first portion of said data packet with mask data from said database, to provide masked packet data;
comparing, using a comparator, said masked packet data with parsing data obtained from said database, and outputting a first comparison result;
forming at least a first portion of a signature word, the at least a first portion of a signature word including said first comparison result wherein said first portion of said signature word is selected in response to data from said database;
comparing at least a second portion of said data packet with parsing data and outputting at least a second comparison result;
forming a second portion of said signature word, different from said first portion, using said second comparison result;
providing associated data in response to said signature word; and
handling said data packet in accordance with said associated data.
42. A method, as claimed in claim 41, further comprising providing a content-addressable memory (CAM) and wherein said step of providing associated data comprises outputting a microcode pointer from said CAM in response to said signature word.
43. A method, as claimed in claim 42, further comprising:
using said microcode pointer to select a microcode entry point; and
executing microcode, beginning at said entry pont, in a microprocessor, for said handling of said data packet.
44. A method, as claimed in claim 41, wherein said outputting said second comparison result is performed substantially simultaneously with said outputting said first, comparison result.
US09/340,256 1999-06-30 1999-06-30 Programmable data packet parser Expired - Lifetime US6611524B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/340,256 US6611524B2 (en) 1999-06-30 1999-06-30 Programmable data packet parser

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/340,256 US6611524B2 (en) 1999-06-30 1999-06-30 Programmable data packet parser

Publications (2)

Publication Number Publication Date
US20030108038A1 US20030108038A1 (en) 2003-06-12
US6611524B2 true US6611524B2 (en) 2003-08-26

Family

ID=23332557

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/340,256 Expired - Lifetime US6611524B2 (en) 1999-06-30 1999-06-30 Programmable data packet parser

Country Status (1)

Country Link
US (1) US6611524B2 (en)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030106049A1 (en) * 2001-11-30 2003-06-05 Sun Microsystems, Inc. Modular parser architecture
US20030185220A1 (en) * 2002-03-27 2003-10-02 Moshe Valenci Dynamically loading parsing capabilities
US20040004956A1 (en) * 2002-07-03 2004-01-08 Agilent Technologies, Inc. Apparatus and method for routing information from a telecommunications network
US20040210727A1 (en) * 2001-08-10 2004-10-21 Gemicer, Inc. Associative memory device
US20050122918A1 (en) * 2003-12-04 2005-06-09 David Johnston Reconfigurable frame parser
US20050256821A1 (en) * 2002-09-06 2005-11-17 Infineon Technologies Ag Parser for parsing data packets
US20060251069A1 (en) * 2000-05-24 2006-11-09 Jim Cathey Programmable Packet Processor with Flow Resolution Logic
US20070174059A1 (en) * 1996-05-16 2007-07-26 Rhoads Geoffrey B Methods, Systems, and Sub-Combinations Useful in Media Identification
US20070189618A1 (en) * 2006-01-10 2007-08-16 Lazar Bivolarski Method and apparatus for processing sub-blocks of multimedia data in parallel processing systems
US7289643B2 (en) * 2000-12-21 2007-10-30 Digimarc Corporation Method, apparatus and programs for generating and utilizing content signatures
US20080059764A1 (en) * 2006-09-01 2008-03-06 Gheorghe Stefan Integral parallel machine
US20080059467A1 (en) * 2006-09-05 2008-03-06 Lazar Bivolarski Near full motion search algorithm
US20080059763A1 (en) * 2006-09-01 2008-03-06 Lazar Bivolarski System and method for fine-grain instruction parallelism for increased efficiency of processing compressed multimedia data
US20080126757A1 (en) * 2002-12-05 2008-05-29 Gheorghe Stefan Cellular engine for a data processing system
US20080244238A1 (en) * 2006-09-01 2008-10-02 Bogdan Mitu Stream processing accelerator
US20080291917A1 (en) * 2007-05-24 2008-11-27 Modelware, Inc. System and method for designing and implementing packet processing products
US20080307196A1 (en) * 2005-10-21 2008-12-11 Bogdan Mitu Integrated Processor Array, Instruction Sequencer And I/O Controller
US20110206064A1 (en) * 2010-02-19 2011-08-25 Intrusion Inc. High speed network data extractor
US8681819B2 (en) 2011-01-31 2014-03-25 International Business Machines Corporation Programmable multifield parser packet
WO2014093208A3 (en) * 2012-12-11 2014-08-21 Agileswitch, Llc Power stack control systems
US9276851B1 (en) 2011-12-20 2016-03-01 Marvell Israel (M.I.S.L.) Ltd. Parser and modifier for processing network packets

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7844687B1 (en) * 1999-10-06 2010-11-30 Gelvin David C Method for internetworked hybrid wireless integrated network sensors (WINS)
US6775284B1 (en) * 2000-01-07 2004-08-10 International Business Machines Corporation Method and system for frame and protocol classification
US20030120800A1 (en) * 2001-12-06 2003-06-26 Edwards Systens Technology, Inc. Network layer protocol
US7379451B1 (en) 2003-04-21 2008-05-27 Xilinx, Inc. Address lookup table
US7620644B2 (en) * 2004-10-19 2009-11-17 Microsoft Corporation Reentrant database object wizard
JP2006333438A (en) * 2005-04-28 2006-12-07 Fujitsu Ten Ltd Gateway apparatus and routing method
US8638793B1 (en) * 2009-04-06 2014-01-28 Marvell Israle (M.I.S.L) Ltd. Enhanced parsing and classification in a packet processor
JP2013511223A (en) * 2009-11-16 2013-03-28 マーベル ワールド トレード リミテッド Iterative analysis and classification
US8966240B2 (en) * 2011-10-05 2015-02-24 Cisco Technology, Inc. Enabling packet handling information in the clear for MACSEC protected frames
US9282173B2 (en) 2012-02-17 2016-03-08 Viavi Solutions Inc. Reconfigurable packet header parsing
US9444914B2 (en) 2013-09-16 2016-09-13 Annapurna Labs Ltd. Configurable parser and a method for parsing information units
US9513926B2 (en) * 2014-01-08 2016-12-06 Cavium, Inc. Floating mask generation for network packet flow

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5414650A (en) 1993-03-24 1995-05-09 Compression Research Group, Inc. Parsing information onto packets using context-insensitive parsing rules based on packet characteristics
US5465322A (en) 1993-01-04 1995-11-07 Xerox Corporation Apparatus and method for parsing a stream of data including a bitmap and creating a table of break entries corresponding with the bitmap
US5509006A (en) * 1994-04-18 1996-04-16 Cisco Systems Incorporated Apparatus and method for switching packets using tree memory
US5608662A (en) * 1995-01-12 1997-03-04 Television Computer, Inc. Packet filter engine
US5805808A (en) 1991-12-27 1998-09-08 Digital Equipment Corporation Real time parser for data packets in a communications network
US5812074A (en) 1996-02-08 1998-09-22 Samsung Electronics Co., Ltd. High speed data syntax parsing apparatus
US5812760A (en) 1996-06-25 1998-09-22 Lsi Logic Corporation Programmable byte wise MPEG systems layer parser
US5881242A (en) 1997-01-09 1999-03-09 International Business Machines Corporation Method and system of parsing frame headers for routing data frames within a computer network
US5978378A (en) * 1997-09-11 1999-11-02 3Com Corporation Method and apparatus for VLAN support
US5991299A (en) * 1997-09-11 1999-11-23 3Com Corporation High speed header translation processing
US6157641A (en) * 1997-08-22 2000-12-05 Cisco Technology, Inc. Multiprotocol packet recognition and switching
US6172980B1 (en) * 1997-09-11 2001-01-09 3Com Corporation Multiple protocol support
US6212183B1 (en) * 1997-08-22 2001-04-03 Cisco Technology, Inc. Multiple parallel packet routing lookup
US6389506B1 (en) * 1998-08-07 2002-05-14 Cisco Technology, Inc. Block mask ternary cam

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5805808A (en) 1991-12-27 1998-09-08 Digital Equipment Corporation Real time parser for data packets in a communications network
US5465322A (en) 1993-01-04 1995-11-07 Xerox Corporation Apparatus and method for parsing a stream of data including a bitmap and creating a table of break entries corresponding with the bitmap
US5414650A (en) 1993-03-24 1995-05-09 Compression Research Group, Inc. Parsing information onto packets using context-insensitive parsing rules based on packet characteristics
US5509006A (en) * 1994-04-18 1996-04-16 Cisco Systems Incorporated Apparatus and method for switching packets using tree memory
US5608662A (en) * 1995-01-12 1997-03-04 Television Computer, Inc. Packet filter engine
US5812074A (en) 1996-02-08 1998-09-22 Samsung Electronics Co., Ltd. High speed data syntax parsing apparatus
US5812760A (en) 1996-06-25 1998-09-22 Lsi Logic Corporation Programmable byte wise MPEG systems layer parser
US5881242A (en) 1997-01-09 1999-03-09 International Business Machines Corporation Method and system of parsing frame headers for routing data frames within a computer network
US6157641A (en) * 1997-08-22 2000-12-05 Cisco Technology, Inc. Multiprotocol packet recognition and switching
US6212183B1 (en) * 1997-08-22 2001-04-03 Cisco Technology, Inc. Multiple parallel packet routing lookup
US5978378A (en) * 1997-09-11 1999-11-02 3Com Corporation Method and apparatus for VLAN support
US5991299A (en) * 1997-09-11 1999-11-23 3Com Corporation High speed header translation processing
US6172980B1 (en) * 1997-09-11 2001-01-09 3Com Corporation Multiple protocol support
US6389506B1 (en) * 1998-08-07 2002-05-14 Cisco Technology, Inc. Block mask ternary cam

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070174059A1 (en) * 1996-05-16 2007-07-26 Rhoads Geoffrey B Methods, Systems, and Sub-Combinations Useful in Media Identification
US7930546B2 (en) 1996-05-16 2011-04-19 Digimarc Corporation Methods, systems, and sub-combinations useful in media identification
US20060251069A1 (en) * 2000-05-24 2006-11-09 Jim Cathey Programmable Packet Processor with Flow Resolution Logic
US7693149B2 (en) * 2000-05-24 2010-04-06 Alcatel-Lucent Usa Inc. Programmable packet processor with flow resolution logic
US8542870B2 (en) 2000-12-21 2013-09-24 Digimarc Corporation Methods, apparatus and programs for generating and utilizing content signatures
US8023773B2 (en) 2000-12-21 2011-09-20 Digimarc Corporation Methods, apparatus and programs for generating and utilizing content signatures
US8077911B2 (en) 2000-12-21 2011-12-13 Digimarc Corporation Methods, apparatus and programs for generating and utilizing content signatures
US8488836B2 (en) 2000-12-21 2013-07-16 Digimarc Corporation Methods, apparatus and programs for generating and utilizing content signatures
US7974436B2 (en) 2000-12-21 2011-07-05 Digimarc Corporation Methods, apparatus and programs for generating and utilizing content signatures
US7289643B2 (en) * 2000-12-21 2007-10-30 Digimarc Corporation Method, apparatus and programs for generating and utilizing content signatures
US7069386B2 (en) * 2001-08-10 2006-06-27 Connex Technology, Inc. Associative memory device
US20040210727A1 (en) * 2001-08-10 2004-10-21 Gemicer, Inc. Associative memory device
US7089541B2 (en) * 2001-11-30 2006-08-08 Sun Microsystems, Inc. Modular parser architecture with mini parsers
US20030106049A1 (en) * 2001-11-30 2003-06-05 Sun Microsystems, Inc. Modular parser architecture
US20030185220A1 (en) * 2002-03-27 2003-10-02 Moshe Valenci Dynamically loading parsing capabilities
US20040004956A1 (en) * 2002-07-03 2004-01-08 Agilent Technologies, Inc. Apparatus and method for routing information from a telecommunications network
US20050256821A1 (en) * 2002-09-06 2005-11-17 Infineon Technologies Ag Parser for parsing data packets
US7616662B2 (en) * 2002-09-06 2009-11-10 Infineon Technologies Ag Parser for parsing data packets
US20080126757A1 (en) * 2002-12-05 2008-05-29 Gheorghe Stefan Cellular engine for a data processing system
US7908461B2 (en) 2002-12-05 2011-03-15 Allsearch Semi, LLC Cellular engine for a data processing system
US7751440B2 (en) * 2003-12-04 2010-07-06 Intel Corporation Reconfigurable frame parser
US20050122918A1 (en) * 2003-12-04 2005-06-09 David Johnston Reconfigurable frame parser
US20080307196A1 (en) * 2005-10-21 2008-12-11 Bogdan Mitu Integrated Processor Array, Instruction Sequencer And I/O Controller
US20070189618A1 (en) * 2006-01-10 2007-08-16 Lazar Bivolarski Method and apparatus for processing sub-blocks of multimedia data in parallel processing systems
US20100066748A1 (en) * 2006-01-10 2010-03-18 Lazar Bivolarski Method And Apparatus For Scheduling The Processing Of Multimedia Data In Parallel Processing Systems
US20080244238A1 (en) * 2006-09-01 2008-10-02 Bogdan Mitu Stream processing accelerator
US20080059763A1 (en) * 2006-09-01 2008-03-06 Lazar Bivolarski System and method for fine-grain instruction parallelism for increased efficiency of processing compressed multimedia data
US20080059764A1 (en) * 2006-09-01 2008-03-06 Gheorghe Stefan Integral parallel machine
US20080059467A1 (en) * 2006-09-05 2008-03-06 Lazar Bivolarski Near full motion search algorithm
US7724684B2 (en) 2007-05-24 2010-05-25 Modelware, Inc. System and method for designing and implementing packet processing products
US20080291917A1 (en) * 2007-05-24 2008-11-27 Modelware, Inc. System and method for designing and implementing packet processing products
US20110206064A1 (en) * 2010-02-19 2011-08-25 Intrusion Inc. High speed network data extractor
US8291058B2 (en) 2010-02-19 2012-10-16 Intrusion, Inc. High speed network data extractor
US8681819B2 (en) 2011-01-31 2014-03-25 International Business Machines Corporation Programmable multifield parser packet
US9276851B1 (en) 2011-12-20 2016-03-01 Marvell Israel (M.I.S.L.) Ltd. Parser and modifier for processing network packets
WO2014093208A3 (en) * 2012-12-11 2014-08-21 Agileswitch, Llc Power stack control systems
US8984197B2 (en) * 2012-12-11 2015-03-17 Agileswitch, Llc Power stack control systems
CN105144131A (en) * 2012-12-11 2015-12-09 灵敏开关有限公司 Power stack control systems

Also Published As

Publication number Publication date
US20030108038A1 (en) 2003-06-12

Similar Documents

Publication Publication Date Title
US6611524B2 (en) Programmable data packet parser
US7299282B2 (en) State processor for pattern matching in a network monitor device
US6611875B1 (en) Control system for high speed rule processors
US6631466B1 (en) Parallel string pattern searches in respective ones of array of nanocomputers
US6771646B1 (en) Associative cache structure for lookups and updates of flow records in a network monitor
US6954789B2 (en) Method and apparatus for monitoring traffic in a network
US9385957B1 (en) Flow key lookup involving multiple simultaneous cam operations to identify hash values in a hash bucket
US7350020B2 (en) Generating and merging lookup results to apply multiple features
US7774497B2 (en) Apparatus and method for classifier identification
US8854996B2 (en) Accelerating data packet parsing
US7095742B2 (en) Packet processing unit
US7689485B2 (en) Generating accounting data based on access control list entries
US7548944B2 (en) Statistics collection framework for a network processor
US6944670B2 (en) Method and apparatus for multiple processing of a plurality of communication protocols on a single processing machine
US7802094B2 (en) Reduction of false positive detection of signature matches in intrusion detection systems
US7539750B1 (en) System and method for packet processor status monitoring
US8767757B1 (en) Packet forwarding system and method using patricia trie configured hardware
US8599859B2 (en) Iterative parsing and classification
US7599364B2 (en) Configurable network connection address forming hardware
US7787463B2 (en) Content aware apparatus and method
US20030007489A1 (en) Data extraction system for packet analysis
WO1996034479A1 (en) Packet switching engine
US20040170172A1 (en) Associative memory entries with force no-hit and priority indications of particular use in implementing policy maps in communication devices
US7529908B2 (en) Method and apparatus for unified exception handling with distributed exception identification
US8427952B1 (en) Microcode engine for packet processing

Legal Events

Date Code Title Description
AS Assignment

Owner name: CISCO TECHNOLOGY INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DEVANAGONDI, HARISH;SUN, JAMES;REEL/FRAME:010073/0596

Effective date: 19990622

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12