Abstract:
The invention provides a method and system for identifying header information in a packet header, and for switching (and otherwise operating) on the packet in response thereto. A first set of header information recognizers operate in parallel on selected words of the packet header so as to recognize a header format for the packet header and to determine header information in response to that header format. A second set of header information recognizers operates on the header information to select a set of words from the packet header which are used for lookup for treatment of the packet. The same or similar header information is located in the packet header responsive to information which determines an encapsulation type for the packet, such as packets which use the IP version 4, IP version 6, or IPX protocols. The header information can include the destination address for the packet, or some combination of the destination address and additional information; the additional information can include the sending address, the input interface, a number of bits matched for the destination address, or some combination thereof.

Description:
This is a continuation of application Ser. No. 08/918,505 filed Aug. 22, 1997, now U.S. Pat. No. 6,157,641. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The invention relates to packet switching. 
     2. Related Art 
     In a packet-switched network, a “router” is a device which receives packets on one or more input interfaces and which outputs those packets on one of a plurality of output interfaces, so as to move those packets within the network from a source device to a destination device. Each packet includes header information which indicates the destination device (and other information), and the router includes routing information which associates an output interface with information about the destination device (possibly with other information). The router can also perform other operations on packets, such as rewriting the packets&#39; headers according to their routing protocol or to reencapsulate the packets from a first routing protocol to a second routing protocol. It is advantageous for routers to operate as quickly as possible, so that as many packets as possible can be switched in a unit time. 
     One problem which has arisen in the art is that packets can be in one of a plurality of routing protocols or encapsulations, and can therefore include header information which the router needs to switch the packet (and to perform other operations on the packet) in locations which vary from packet to packet. This requires the router to be able to locate the header information in one or more of various locations within the packet. Thus, methods by which the router might operate relatively quickly can be inflexible with regard to the location for the header information, while methods by which the router might operate flexibly with regard to the location for the header information can be relatively slow. 
     Some known routers, such as those described in U.S. Pat. No. 5,509,006, “Apparatus and Method for Switching Packets Using Tree Memory”, issued Apr. 16, 1996, in the name of inventor Bruce A. Wilford, and assigned to cisco Systems, Inc., can determine a type for the packet and therefore the location of the header information, by examining each byte of the packet header in turn. Thus, each byte of the packet header provides information regarding interpretation of successive bytes of the packet header, and the router can determine the header information needed to switch the packet in response to the relatively early bytes of the packet header. While this method achieves the goal of being relatively flexible with regard to the location for the header information, it can take many clock cycles to determine the proper header information, and is therefore not as relatively quick as desired. 
     Accordingly, it would be desirable to provide a method and system for locating header information in packet headers and switching packets in response to that header information, which is both relatively quick and flexible with regard to location of the header information. This advantage is achieved in an embodiment of the invention in which header information recognizers operate in parallel on the packet header to determnine the location of the header information, and the packet is switched responsive to the header information so located. 
     SUMMARY OF THE INVENTION 
     The invention provides a method and system for identifying header information in a packet header, and for switching (and otherwise operating on) the packet in response thereto. A first set of header information recognizers operate in parallel on the packet header so as to recognize a header format for the packet header and to determine relevant header information in response to that header format. A second set of header information recognizers operates on the header information to select one or more sets of words from the header information which are used for one or more lookups for treatment of the packet. 
     In a preferred embodiment, the same or similar header information is located in the packet header responsive to information which determines an encapsulation type for the packet, such as packets which use the IP version 4, rP version 6, or IPX protocols. The header information can include the destination address for the packet, or some combination of the destination address and additional information; the additional information can include the sending address, the input interface, a number of bits matched for the destination address, or some combination thereof. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 shows a block diagram of a system including a multiprotocol packet recognizer and switcher. 
     FIG. 2 shows a block diagram of a multiprotocol packet recognizer and switcher. 
     FIG. 3 shows a recognizer element for a multiprotocol packet recognizer and switcher. 
     FIG. 4 shows a multiplexer element for a multiprotocol packet recognizer and switcher. 
     FIG. 5 shows an example input packet header before and after processimg by elements of the multiprotocol packet recognizer and switcher. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     In the following description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures. Those skilled in the art would recognize after perusal of this application that embodiments of the invention can be implemented using general purpose processors or special purpose processors or other circuits adapted to particular process steps and data structures described herein, and that implementation of the process steps and data structures described herein would not require undue experimentation or further invention. 
     Inventions described herein can be used in conjunction with inventions described in the following applications: 
     Application Ser. No. 08/917,654, filed the same day, Express Mail Mailing No. EM266118235US, in the name of the.same inventor, titled “Multiple Parallel Packet Routing Lookup”, now U.S. Pat. No. 6,212,183; and 
     Application Ser. No. 08/918,506, filed the same day, Express Mail Mailing No. EM571204544US, in the name of the same inventor, titled “Enhanced Internet Packet Routing Lookup”. 
     Each of these applications is hereby incorporated by reference as if fully set forth herein. 
     System Including Multiprotocol Multipacket Recognizer and Switcher 
     FIG. 1 shows a block diagram of a system including a multiprotocol packet recognizer and switcher. 
     A system  100  includes a packet source  110 , a packet input queue  120 , a multiprotocol packet recognizer  130 , a packet queue  140 , a rewrite element  150 , and a packet output queue  160 . 
     The input queue  120  is coupled to the source  110 , receives a sequence of packets  111  from the source  110 , and queues them in a first-in first-out (FIFO) manner. In a preferred embodiment, the source  110  comprises a plurality of network interfaces on which packets  111  can be received. 
     The recognizer  130  is coupled to the input queue  120 , receives packet headers  112  from the input queue  120  (along with associated packet identifiers  113 ), routes the associated packets  111 , and transmits the identifiers  113  and associated routing results  114  for the packets  111  to the rewrite element  150 . The recognizer  130  uses a lookup element  131 , a statistics memory  132 , and a processor  133 . 
     The packet queue  140  is coupled to the input queue  120 , receives packets  111  (along with associated identifiers  113 ) from the input queue  120 , and transmits them to the rewrite element  150  in a first-in first-out manner. 
     The rewrite element  150  is coupled to the recognizer  130  and the packet queue  140 . The rewrite element  150  receives packets  111  (including their headers  112 ), identifiers  113 , and routing results  114  from the recognizer  130  and the packet queue  140 . 
     The rewrite element  150  includes a joiner module  151 , which matches the packets  111  and their routing results  114  using the identifiers  113 . The rewrite element  150  also includes a rewrite module  152 , which rewrites the packets  111  using the routing results  114  and using a rewrite memory  153  to generate rewritten packets  111 . In a preferred embodiment, the joiner module  151  thus performs the function of reordering the packets  111  in the packet queue  140  into a routing result order before those packets  111  are rewritten by the rewrite element  150 . 
     The output queue  160  is coupled to the rewrite element  150 , receives packets  111  therefrom, and queues them for output to designated interfaces in a first-in first-out manner. 
     Multiprotocol Multipacket Recognizer and Switcher 
     FIG. 2 shows a block diagram of a multiprotocol packet recognizer and switcher. 
     The recognizer  130  includes a packet buffer  210 , a set of n encapsulation recognizers  220 , an encapsulation multiplexer  230 , a set of m longest-match recognizers  240 , and a set of m longest-match multiplexers  250 . 
     The packet buffer  210  is coupled to the input queue  120  and receives packet headers  112  from the input queue  120 . 
     Each of the n encapsulation recognizers  220  is coupled to the packet buffer  210 , and includes a set of recognizer elements  221  (FIG.  3 ). There is one recognizer element  221  for each word of the packet buffer  210 , and one or more of the recognizer elements  221  provides a recognizer output word  222 . In a preferred embodiment, each word comprises one eight-bit octet or byte. The recognizer elements  221  of each encapsulation recognizer  220  use a set of recognizer instructions  260 . 
     The recognizer elements  221  of each of the n encapsulation recognizers  220  collectively perform a bytewise comparison of the packet header  112 . For each recognizer element  221 , the nature of the bytewise comparison is defined by the recognizer instruction  260  for that recognizer element  221 . If the comparisons by the recognizer elements  221  of a particular encapsulation recognizer  220  are successful, the recognizer elements  221  use the recognizer instructions  260  to generate one or more associated recognizer output words  222 . 
     FIG. 5 shows an example input packet header before and after processing by elements of the multiprotocol packet recognizer and switcher. 
     In the example shown in FIG. 5, the packet header  112  comprises the header for an input Ethernet packet. Each of the encapsulation recognizers  220  performs a bytewise comparison of the packet header  112  with header information tag words associated with an associated header format for that particular encapsulation recognizer  220 . In a preferred embodiment, there can be one or more such encapsulation recognizers  220  for each substantially different header format. Each of the encapsulation recognizers  220  thus recognizes and confirms some information such as the input interface type (which might, for example, be the value hexadecimal 01 for “Ethernet”) and the longest-match protocol type (which must be the value hexadecimal 08 00 for “IP”). Each of the encapsulation recognizers  220  recognizes and discards other information such as the input interface number (which can be any value), and recognizes still other information such as the source address and destination address and generates recognizer output words  222  corresponding to those values. 
     The encapsulation multiplexer  230  is coupled to the one of the n encapsulation recognizers  220  which successfully matches the input packet header. The n encapsulation recognizers  220  are coupled to a priority selector, so that if more than one of encapsulation recognizers  220  successfully match the input packet header, only one of those encapsulation recognizers  220  is coupled to the encapsulation multiplexer  230 . 
     The encapsulation multiplexer  230  includes a set of rows  410  of multiplexer elements  231  (FIG.  4 ); a first row  410  includes one less multiplexer element  231  than the number of recognizer output words  222  received from the encapsulation recognizer  220 . The encapsulation multiplexer  230  provides a number of multiplexer output words  232  equal to the number of non-null recognizer output words  222 ; these multiplexer output words  232  have been coalesced by left-shifting. The multiplexer elements  231  of the encapsulation multiplexer  230  thus collectively perform a bytewise shift of all non-null recognizer output words  222  so as to eliminate null recognizer output words  222  from processing by further stages of the recognizer  130 . 
     In the example shown in FIG. 5, there are about eight encapsulation recognizers  220 , one for each of the following protocols: IP, IP multicast, TAG switching, TAG switching (multicast), IPX, CLNS, and two extra encapsulation recognizers  220  for future expansion. One of the encapsulation recognizers  220  generates a set of recognizer output words  222  corresponding to Ethernet header format, and the encapsulation multiplexer  230  collects the non-null recognizer output words  222  so as to generate a compact form of the packet header  112  which is specific to Ethernet header format. This compact form comprises a set of type information possibly equal to the value hexadecimal 08 (for example), a set of type-of-service information typically equal to the value hexadecimal 60, a set of protocol information typically equal to the value hexadecimal 06, a source IP address equal in the example shown in FIG. 5 to the value hexadecimal 81 2B 25 5C, and a destination IP address equal in the example shown in FIG. 5 to the value hexadecimal 80 10 05 1F. 
     Each of the m longest-match recognizers  240  is coupled to the encapsulation multiplexer  230 , and includes a set of recognizer elements  221  (FIG.  3 ). There is one recognizer element  221  for each multiplexer output word  232 , and one or more of the recognizer elements  221  provides a recognizer output word  222  (FIG.  3 ). The recognizer elements  221  of each of the m longest-match recognizers  240  also use the recognizer instructions  260 . 
     Each of the m longest-match recognizers  240  is also coupled to a checksum element  270 , which includes a checksum multiplexer  271  and a checksum computing element  272 . The checksum multiplexer  271  is coupled to the packet buffer  210 . The recognizer instructions  260  select a set of words from the packet buffer  210  for which a checksum is to be computed. The checksum computing element  272  computes the checksum from the selected words. The checksum element  270  calculates packet header checksums in parallel on the input packet header according to each of multiple header encapsulation protocols. The result of each packet header checksum is output on a separate bit. The longest-match recognizers  240  for a protocol encapsulation each check the corresponding bit for that protocol encapsulation. Protocols with header checksums, such as IP version 4 or CLNS, are therefore suitable for use with the checksum element  270 . 
     Each of the m longest-match multiplexers  250  is coupled to a corresponding one of the m longest-match recognizers  240 . 
     Similar to the encapsulation multiplexer  230 , each one of the m longest-match multiplexers  250  includes a set of multiplexer elements  231  (FIG.  4 ). Similar to the encapsulation recognizer  220  and the encapsulation multiplexer  230 , there is one less multiplexer element  231  than the number of recognizer output words  222  received from the corresponding longest-match recognizer  240 , and the longest-match multiplexer  250  provides a number of multiplexer output words  232  equal to the number of non-null recognizer output words  222 . 
     In the example shown in FIG. 5, a particular subset of the longest-match recognizer  240  generates sets of recognizer output words  222  corresponding to IP header format, and those longest-match multiplexers  250  collect the non-null recognizer output words  222  so as to generate a set of information for routing lookup. For IP routing, this set of information preferably comprises the source IP address (equal in the example shown in FIG. 5 to the value hexadecimal 81 2B 25 5C) and the destination IP address (equal in the example shown in FIG. 5 to the value hexadecimal 80 10 05 1F). Because the number of bits used for IP lookup is variable, there will be a plurality of (preferably about six) longest-match recognizers  240  in the particular subset for IP header format. 
     In a preferred embodiment in which IP multicast routing is also performed, in the particular subset of the longest-match recognizers  240  which generate sets of recognizer output words  222  corresponding to IP multicast header format, the source IP address and the destination IP address are used for (s, g) routing lookup and the destination IP address is used for (*, g) routing lookup. Thus there are two longest-match recognizers  240  in the particular subset for IP multicast header format. 
     In a preferred embodiment in which TAG switching routing is also performed, the number of bits used in the lookup is constant, so there is only a single longest-match recognizer  240  in the particular subset for TAG switching header format. 
     The lookup element  131  is coupled to the m longest-match multiplexers  250 , and generates the routing results  114 , which are coupled to the rewrite element  150 , and a set of routing statistics  265 , which are coupled to a statistics collection point  266 . 
     In a preferred embodiment, the lookup element  131  is that shown and described in application Ser. No. 08/917,654, filed the same day, Express Mail. Mailing No. EM266118235US, in the name of the same inventor, titled “Multiple Parallel Packet Routing Lookup”, now U.S. Pat. No. 6,212,183, and in application Ser. No. 08/918,506, filed the same day, Express Mail Mailing No. EM571204544US, in the name of the same inventor, titled “Enhanced Internet Packet Routing Lookup”, both applications of which are hereby incorporated by reference as if fully set forth herein. 
     In a preferred embodiment (as described in incorporated applications Ser. Nos. 08/917,654  020 B and 08/918,506), the lookup element  131  includes an external memory for storing routing lookup tables comprising a set of routing lookup entries, a hashing element for generating a hash key for indexing to the routing lookup tables, a comparison element for comparing corresponding routing lookup entries with actual routing information (such as for example the destination IP address from the packet  111 , and an IP route from a routing protocol), and a memory controller for controlling transfer of hash keys to the external memory and transfer of routing lookup entries from the external memory. 
     However, in alternative embodiments the lookup element  131  may comprise any lookup element capable of determining the routing results  114  responsive to packet header information, such as the following: 
     lookup elements found in known routing devices; 
     lookup elements described in U.S. Pat. No. 5,509,006, “Apparatus and Method for Switching Packets Using Tree Memory”, issued Apr. 16, 1996, in the name of inventor Bruce A. Wilford, and assigned to cisco Systems, Inc., or 
     lookup elements described in U.S. application Ser. No. 08/655,429, “Network Flow Switching and Flow Data Export”, filed May 28, 1996, in the name of inventors Darren Kerr and Barry Bruins, and assigned to cisco Systems Inc., now U.S. Pat. No. 6,243,667, or in U.S. application Ser. No. 08/771,438, having the same title, filed Dec. 19, 1996, in the name of the same inventors, assigned to the same assignee, now U.S. Pat. No. 6,308,148. 
     In such alternative embodiments, the lookup element  131  may be disposed for receiving more than one set of packet header information for lookup, such as the m sets of multiplexer output words  232  from the m longest-match multiplexers  250 . of the instruction word  330  is performed in response to the result of the comparison, and can cause an output word to be generated for the recognizer element  221 . 
     The instruction word  330  includes a checksum field  331 , an up field  332 , an accept field  333 , and an output field  334 . 
     The checksum field  331  indicates whether the input word  301  is transmitted to the checksum element  270 . 
     The up field  332  indicates whether the packet  111  should be handled by an exception handler at a higher software level. If the up field  332  is asserted and the accept field  333  does not indicate acceptance of the inputs, the packet  111  is passed “up” to the processor  133  for exceptional handling. 
     The accept field  333  indicates under what conditions the inputs are accepted by the recognizer element  221 . The accept field  333  comprises an entry indicating an operation and a comparison to be performed on the inputs (PB), the mask value (M 0 ), and the expected word value (EV). In a preferred embodiment, the accept field  333  can indicate one of the following entries: 
     NO or YES. 
     The inputs are never accepted (“NO”) or always accepted (“YES”). 
     Equal (Masked  1 ), Equal (Masked  2 ) 
     The inputs are masked with one of the two global mask values (“Masked  1 ” or “Masked  2 ”) and compared for equality with the expected-word value. 
     Equal, Less-Than, Greater-Than, Not-Equals 
     The unmasked inputs are compared with the expected-word value; the comparison is accepted if the inputs are correspondingly equal to, less than, or greater than, the expected-word value. 
     The output field  334  indicates an output word from the output port  340 . The output field  334  comprises an entry indicating a value or combination of values to be output, if the accept field  333  indicates that the inputs are accepted by the recognizer element  221 . In a preferred embodiment, the output field  334  can indicate one of the following entries: 
     Nothing. 
     An output value at the output port is undefined and a valid entry at the output port is set to INVALID. 
     Input Value (PB). 
     The output value is equal to the input value, and the valid entry is set to VALID. 
     Recognizer Element 
     FIG. 3 shows a recognizer element for a multiprotocol packet recognizer and switcher. 
     The recognizer elements  221  each include an input port  300 , a set of masks  310 , an expected-word value  320 , an instruction word  330  (received from the recognizer instructions  260 ), and an output port  340 . 
     The input port  300  is coupled to a set of inputs. For the encapsulation recognizers  220  these inputs each include one corresponding word  301  of the packet buffer  210 ; for the longest-match recognizers  240  these inputs include one corresponding multiplexer output word  232  from the encapsulation multiplexer  230  and a valid bit  302 . 
     The inputs are each masked in response to control by an instruction word  330  by a set of mask values input from the masks  310 . In a preferred embodiment, there is at least one global mask which is applied as one of the masks  310  to each of the recognizer elements  221 . 
     The inputs are each compared with the expected-word value  320  under control of the instruction word  330 . A result of the comparison is output from the recognizer element  221  as an accept value  345  (described herein). An output field  334   
     Expected-Word Value (EV). 
     The output value is equal to the expected-word value, and the valid entry is set to VALID. 
     Combination of Input Value and Expected-Word Value (PB &amp; EV). 
     The output value is equal to the logical AND of the input value and the expected-word value, and the valid entry is set to VALID. 
     The output port  340  includes an output value  341 , a valid entry  342 , a checksum value  343 , an up value  344 , and an accept value  345 . The output value  341  and the valid entry  342  are generated as shown above with reference to the output field  334 . The checksum value  343  is generated as shown above with reference to the checksum element  270  and the checksum field  331 . The up value  344  is generated as shown above with reference to the up field  332 . 
     The accept value  345  is generated as shown above with reference to the accept field  333 , and indicates that the particular recognizer element  221  has met its comparison test. The encapsulation recognizer  220  and each longest-match recognizer  240  each accept a packet header only when all their corresponding recognizer elements  221  have their accept values  345  simultaneously asserted. 
     Multiplexer Element 
     FIG. 4 shows a multiplexer for a multiprotocol packet recognizer and switcher. 
     The multiplexer elements  231  for the encapsulation multiplexer  230  or the longest-match multiplexer  250  are each disposed in an array of rows  410 . A first row  410  includes one less multiplexer element  231  than a number of input recognizer output words  222 . Each successive row  410  includes one fewer multiplexer element  231 . A final row  410  includes one multiplexer element  231  for each output multiplexer output word  232 . 
     Each multiplexer element  231  has a corresponding right neighbor multiplexer element  231  (in the same row  410 ), a corresponding left neighbor multiplexer element  231  (in the same row  410 ), two corresponding top neighbor multiplexer elements  231  (in an earlier row  410 ), and two corresponding down neighbor multiplexer elements  231  (in a later row  410 ), except for multiplexer elements  231  at borders of the array. 
     Each multiplexer element  231  includes a left data input  400 , a right data input  401 , a left valid input  402 , a right valid input  403 , a data output  404 , a valid output  405 , a left-full input  406 , and a left-full output  407 . 
     The left data input  400  and the right data input  401  are coupled to the data outputs  404  for two corresponding top neighbor multiplexer elements  231 . For a top row of multiplexer elements  231 , the left data input  400  and the right data input  401  are instead coupled to corresponding recognizer output words  222 . The left valid input  402  and the right valid input  403  are similarly coupled to the valid outputs  405  for the same two corresponding top neighbor multiplexer elements  231 . 
     The data output  404  is coupled to the left data input  400  and the right data input  401  for two corresponding down neighbor multiplexer elements  231 . For a bottom row of multiplexer elements  231 , the data output  404  is coupled to a multiplexer output word  232  for the encapsulation multiplexer  230  or for the longest-match multiplexer  250 . Similarly, the valid output  405  is coupled to the left valid input  402  and the right valid input  403  for two corresponding down neighbor multiplexer elements  231 . 
     Each row of multiplexer elements  231  operates to transfer valid data inputs toward the left side for the next row, so that at the bottom row of multiplexer elements  231 , all valid data inputs have been collected at the left side, and all other entries indicate lack of valid data. 
     Thus, for multiplexer elements  231  at the leftmost position of any row  410 , if either the left valid input  402  or the right valid input  403  is asserted, the valid output  405  is asserted. If the left data input  400  has valid data (that is, the left valid input  402  is asserted), that valid data is output at the data output  404 , and the left-full output  407  is asserted. Otherwise, if the right data input  401  has valid data (that is, the right valid input  403  is asserted), that valid data is output at the data output  404 , and the left-full output  407  is not asserted. 
     For multiplexer elements  231  which are not at the leftmost position of any row  410 , if the left-full input  406  is asserted, the multiplexer element  231  performs similarly to those multiplexer elements  231  at the leftmost position of any row  410  (because all multiplexer elements  231  further left are “full”). If the left-full input  406  is not asserted, the multiplexer element  231  transmits the data from its right data input  401  to its data output  404  and transmits the signal from its right valid input  403  to its valid output  405 . 
     Each multiplexer element  231  asserts its left-full output  407  if and only if its left-full input  406  and its left valid input  402  are both asserted. Each multiplexer element  231  asserts its valid output  405  if either its left-full output  407  is asserted or its right valid input  403  is asserted. 
     Alternative Embodiments 
     Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those skilled in the art after perusal of this application.