HIERARCHICAL POLICERS FOR ENFORCING DIFFERENTIATED TRAFFIC BEHAVIOR

Abstract

A hierarchical traffic policer may include a first policer configured to pass first packets when a first condition is met. The first policer also may alter selection information within the passed first packets. A second policer may be configured to pass second packets when a second condition is met. The second policer may be further configured to pass all of the passed first packets from the first policer based on the altered selection information within the passed first packets.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to processing network traffic, and more particularly, to the policing of network traffic to confirm to a desired service.

2. Description of Related Art

Routers receive data on a physical media, such as optical fiber, analyze the data to determine its destination, and output the data on a physical media in accordance with the destination. Routers were initially designed using a general purpose processor executing large software programs. As line rates and traffic volume increased, however, general purpose processors could not scale to meet these new demands. For example, as functionality was added to the software, such as accounting and policing, these routers suffered performance degradation. In some instances, the routers failed to handle traffic at line rate when the new functionality was implemented.

To meet the new demands, purpose-built routers were designed with components optimized for routing. These routers not only handle higher line rates and higher network traffic volume, they also add functionality without compromising line rate performance.

A purpose-built router may include a number of input and output ports from which it transmits and receives information packets. A packet received at one port is typically directed to its appropriate output port based on an examination and processing of the packet's header information, which includes an indication of the packet's destination. A high-performance router must accordingly examine and process the information packets at a high speed.

It may be desirable to provide a certain level of service in a purpose-built router, for example using a policer, rather than a queue. FIG. 1 is a block diagram illustrating an exemplary token bucket policer 100. Policer 100 may include, conceptually, a token bucket 110 and a number of credits 120 in bucket 110. Those skilled in the art will appreciate that policer 100 may be implemented using software, hardware, or some combination of both.

In practice, policer 100 may be used to impose some level of service on entering packets, for example by rate limiting traffic. In such a case, a packet is passed through policer 100 if a sufficient number of credits 120 (e.g., proportional to a size of the packet) is present in bucket 110. If the sufficient number of credits 120 is present, this number of credits 120 is removed from bucket 110 when the packet is passed. If the sufficient number of credits 120 is not present, however, the packet may “fail” and may be dropped, marked as non-conforming, etc. More credits 120 may be periodically added to bucket 110 at a rate that corresponds to the overall bandwidth of policer 100. Further, the size of bucket 110 (i.e., an upper limit on the number of credits 120 that will fit in bucket 110, if applicable) may correspond to a maximum burst size allowed by policer 100.

Such a policer 100 may create a bandwidth-limited service, or other type of desired service, within a purpose-built router or other network device. When differentiated levels of service (e.g., high priority, low priority, premium, ordinary, etc.) are desired, however, such policers may have difficulty in properly handling different types of packets.

Thus, it is desirable to police network traffic to confirm to desired levels of service in high-performance routers and other network devices.

SUMMARY OF THE INVENTION

Systems and methods consistent with the principles of the invention, among other things, provide for improved policing of traffic with different levels of service.

In accordance with one purpose of the invention as embodied and broadly described herein, a hierarchical policer may include a sorter configured to separate data of a first type from data of a second type. A first policer may be configured to police the data of the first type from the sorter. A second policer may be configured to selectively police the data of the second type from the sorter and data of the first type from the first policer.

In another implementation consistent with the principles of the invention, a hierarchical traffic policer may include a first policer configured to pass first packets when a first condition is met. The first policer also may alter selection information within the passed first packets. A second policer may be configured to pass second packets when a second condition is met. The second policer may be further configured to pass all of the passed first packets from the first policer based on the altered selection information within the passed first packets.

In a further implementation consistent with the principles of the invention, a method for policing traffic may include separating high priority data and low priority data and determining a threshold amount of high priority credit based on a unit of high priority data. The unit of high priority data may be approved to produce a unit of approved data when a present amount of high priority credit exceeds the threshold amount of high priority credit. A threshold amount of low priority credit may be ascertained based on a unit of low priority data. The unit of low priority data may be allowed when a present amount of low priority credit exceeds the threshold amount of low priority credit. The unit of approved data may be passed without considering the present amount of low priority credit.

In yet another implementation consistent with the principles of the invention, a method for policing traffic may include setting meta-data in a plurality of packets of information and policing a first set of the packets of information. The meta-data in packets of the first set that passed the policing may be changed. A second set of the packets of information may be selectively policed based on the meta-data in the second set of packets.

In still a further implementation consistent with the principles of the invention, a network device for processing packets may include a buffer configured to store the packets, including header data and payload data for the packets. A packet routing component may be coupled to the buffer. The packet routing component may be configured to perform packet routing based on header data from the buffer. The packet routing component may include a first policer configured to pass first header data when a first condition is met and to alter selection information within the passed first packets. The packet routing component also may include a second policer configured to pass second header data when a second condition is met. The second policer may be further configured to pass all of the passed first header data from the first policer based on the altered selection information within the passed first header data.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings,

FIG. 1 is a block diagram conceptually illustrating a token bucket policer;

FIG. 2 is a block diagram illustrating an exemplary routing system in which principles consistent with the invention may be implemented;

FIG. 3 is an exemplary detailed block diagram illustrating portions of the routing system shown in FIG. 2;

FIG. 4 is a diagram illustrating portions of FIG. 3 in additional detail;

FIG. 5 is a diagram illustrating a policer consistent with the principles of the invention; and

FIG. 6 is a flow chart illustrating operation of the policer of FIG. 5 consistent with the principles of the invention.

DETAILED DESCRIPTION

The following detailed description of the invention refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents of the claim limitations.

As described herein, a hierarchical policer may include at least two policers that either normally police traffic or pass the traffic without policing based on certain data within the traffic. The certain data may be changed after normal policing.

System Configuration

FIG. 2 is a block diagram illustrating an exemplary routing system 200 in which the present invention may be implemented. System 200 receives a data stream from a physical link, processes the data stream to determine destination information, and transmits the data stream out on a link in accordance with the destination information. System 200 may include packet forwarding engines (PFEs) 210a, 210b, . . . , 210n (collectively, 210), a switch fabric 220, and a routing engine (RE) 230.

RE 230 performs high level management functions for system 200. For example, RE 230 communicates with other networks and systems connected to system 200 to exchange information regarding network topology. RE 230 creates routing tables based on network topology information, creates forwarding tables based on the routing tables, and forwards the forwarding tables to PFEs 210. PFEs 210 use the forwarding tables to perform route lookup for incoming packets. RE 230 also performs other general control and monitoring functions for system 200.

PFEs 210 are each connected to RE 230 and switch fabric 220. PFEs 210 receive data at ports on physical links connected to a network, such as a wide area network (WAN), a local area network (LAN), or a device. Each physical link could be one of many types of transport media, such as optical fiber or Ethernet cable. The data on the physical link is formatted according to one of several protocols, such as the synchronous optical network (SONET) standard or Ethernet.

PFEs 210 process incoming data by stripping off the data link layer. PFEs 210 convert header information from the remaining data into data structures referred to herein as “notifications” and “cells” (where a cell may be a fixed length data unit). For example, in one embodiment, the data remaining after the data link layer is stripped off is packet data. PFEs 210 include the layer 2 (L2) and layer 3 (L3) packet header information, some control information regarding the packets, and the packet data in a series of cells called “D” cells. In one embodiment, the L2, L3, and the control information are stored in the first two cells of the series of cells.

In general, L2 header information refers to header information used to steer packets within LANs. L3 header information, in contrast, provides connectivity between different LANs. In this sense, the L3 header information provides higher level destination information than the L2 header. An incoming packet may include both L2 and L3 header information. Router 200 may modify the packet's L2 and L3 header information before transmitting the packet to its next destination.

PFEs 210 form a notification based on the L2, L3, and control information, and performs a route lookup using the notification and the routing table from RE 230 to determine destination information. PFEs 210 may also further process the notification to perform protocol-specific functions, policing, and accounting, and might even modify the notification to form a new notification.

If the determined destination indicates that the packet should be sent out on a physical link connected to a particular one of PFEs 210, then the PFE retrieves the cells for the packet, converts the notification or new notification into header information, forms a packet using the packet data from the cells and the header information, and transmits the packet from the port associated with the physical link.

If the destination indicates that the packet should be sent to another PFE via switch fabric 220, then the PFE retrieves the cells for the packet, modifies the first two cells with the new notification and new control information, if necessary, and sends the cells to the other PFE via switch fabric 220. Before transmitting the cells over switch fabric 220, PFEs 210 append a sequence number to each cell, which allows the receiving PFE to reconstruct the order of the transmitted cells. Additionally, the receiving PFE uses the notification to form a packet using the packet data from the cells, and sends the packet out on the port associated with the appropriate physical link of the receiving PFE.

In summary, in one embodiment, RE 230, PFEs 210, and switch fabric 220 perform routing based on packet-level processing. PFEs 210 store each packet in cells while performing a route lookup using a notification, which is based on packet header information, including L2 and L3 layer header information. A packet might be received on one PFE and go back out to the network on the same PFE, or be sent through switch fabric 220 to be sent out to the network on a different PFE.

FIG. 3 is an exemplary detailed block diagram illustrating portions of routing system 200. PFEs 210 connect to one another through switch fabric 220. Each of the PFEs may include one or more physical interface cards (PICs) 310a, 310b (collectively, 310) and a flexible port concentrators (FPC) 320.

Each of PICs 310 may transmit data between a physical link and FPC 320. Different PICs are designed to handle different types of physical links. For example, one of PICs 310 may be an interface for an optical link while another PIC may be an interface for an Ethernet link.

FPC 320 performs routing functions and handle packet transfers to and from PICs 310 and switch fabric 220. For each packet it handles, an FPC performs the previously-discussed route lookup function. Although FIG. 3 shows two PICs connected to FPC 320 and three FPCs connected to switch fabric 220, in other embodiments consistent with principles of the invention there can be more or fewer PICs 310 and FPCs.

FIG. 4 is an exemplary configuration of FPC 320 according to an implementation consistent with the principles of the invention. FPC 320 may include processing units 432 and 434, a first input/output (I/O) unit 436, a second I/O unit 438, a memory unit 440, and an R unit 442. Each processing unit 432 and 434 corresponds to one or more of PICs 310.

As will be described in greater detail below, processing units 432 and 434 may process packet data flowing between PICs 310 and first I/O unit 436. Each processing unit 432 and 434 may process packet data received from the PIC connected to it, and data received from first I/O unit 436.

For example, processing unit 432 or 434 may process packets from PICs 310 to convert the packets into data cells, and transmit the data cells to first I/O unit 436. Data cells are the data structure used by FPC 320 internally for transporting and storing data. In one implementation, data cells are 64 bytes in length.

In the other direction, processing unit 432 or 434 receives data cells and notifications from first I/O unit 436, extracts certain information and packet data from the data cells, and creates a packet based on the extracted information. Processing unit 432 or 434 creates the packet header based on the information extracted from the data cells. In one embodiment, processing unit 432 or 434 creates L2 and L3 header information based on the extracted information. The created L2 and L3 header information constitutes a new header that the packet uses as it is subsequently transmitted through the physical link.

R unit 442 may receive notifications from first I/O unit 436 and second I/O unit 438. R unit 442 may provide a variety of functions, such as route lookup, accounting, and policing functionality, based on the notifications. R unit 442 may receive one or more forwarding tables from RE 230 (FIG. 2) and use keys, forwarding table(s), and encapsulation tables to perform route or encapsulation lookups. R unit 442 may insert the lookup result into a notification, which it may store in memory unit 440.

Memory unit 440 may temporarily store data cells from first I/O unit 436 and second I/O unit 438 and notifications from R unit 442. Memory unit 440 may dispatch the notifications to first I/O unit 436 and second I/O unit 438. In response, first I/O unit 436 and second I/O unit 438 may use address information in the notification to read out data cells from memory unit 440 that correspond to a notification. The notification received from memory unit 440 may have been modified by R unit 442 with route or encapsulation lookup results. First I/O unit 436 and second I/O unit 438 may update the data cells read out of memory unit 440 with information from the modified notification. The data cells, which now include information from the modified notification, are sent to processing unit 432, processing unit 434, or switch fabric 220, depending on which of first I/O unit 436 or second I/O unit 438 is processing the notification.

Exemplary Traffic Policer

A hierarchical policer consistent with the principles of the invention herein may be used in system 200 described above, but could be used in any device (e.g., a network device) that polices traffic. For example, a policer consistent with the principles of the invention may be used at the ingress of system 200 (e.g., processing unit 432 or 434) and/or in the route lookup part of the system 200 (e.g., R unit 442). It may be used, however, anywhere in the path through a router or network device. The policer described herein may police packets or items representing packets, such as notifications.

One service example, in which context a policer consistent with the principles of the invention will be discussed, involves differentiation between “premium” traffic (e.g., high priority) and “ordinary” traffic (e.g., low priority). For the sake of discussion, suppose that one wishes to admit 1 Mbps of total traffic into a network (with 100 kb maximum burst size), and that within the total traffic, up to 200 kbps may be premium traffic (with 20 kb maximum burst size). Further, if the total traffic exceeds 1 Mbps, only the ordinary traffic should be dropped. The following exemplary traffic policer and its operation will be discussed in the context of this dual-priority example. It should be noted, however, that the principles of the invention are applicable to any number of differentiated traffic service levels.

FIG. 5 is a diagram illustrating a hierarchical policer 500 consistent with the principles of the invention. Policer 500 may include a sorter 510, a high priority policer 520, and a low priority policer 530. Policer 500 and its components may be implemented in logic, a general purpose processor, a special purpose processor, or some combination thereof.

Sorter 510 may sort premium traffic from ordinary traffic, and route packets of each type accordingly. Although policer 500 will be described in terms of processing packets, it should be understood that in another embodiment policer 500 processes data (e.g., notifications) associated with respective packets. Sorter 510 also may be configured to set one or more bits of meta-data (i.e., data about the data in the packet) in each packet, called the Normal Policer Instruction (NPI), to a common value. The NPI may be referred to generically as “selection information” or a “flag” in the packet. With their respective NPIs set (e.g., to logical “1”), sorter 500 may be configured to send premium packets to the high priority policer 520 and ordinary packets to the low priority policer 530. Sorter 510 need not set the NPI value; it may already be set by default when the header information is created.

High priority policer 520 may be configured to perform “normal” token bucket-type policing on premium packets, based on their NPI value of 1. That is, high priority policer 520 may be configured to pass on any premium packets that conform to its bandwidth/burst rate requirements (e.g., 200 kbps and 20 kb) to the low priority policer 530 and fail any packets that do not. High priority policer 520 may implement an appropriate bucket size, credit add rate, and proportional credit removal, as explained above with respect to FIG. 1. For example, its “bucket” may be a value in memory or a register that is adjusted upward and downward as appropriate. Failed premium packets may be dropped or marked as non-conforming, possibly in conjunction with other processing such as counting the number of such packets.

High priority policer 520 also may be configured to change (i.e., reset/toggle/clear) the NPI to a different value (e.g., logical “0”) for premium packets that it passes on to the low priority policer 530.

Low priority policer 530 may be configured to perform “normal” token bucket-type policing on ordinary packets, based on their NPI value of 1. That is, low priority policer 530 may be configured to pass on any ordinary packets that conform to its bandwidth/burst rate requirements (e.g., 1 Mbps and 100 kb) and fail any ordinary packets that do not. Low priority policer 530 may implement an appropriate bucket size, credit add rate, and proportional credit removal, as explained above with respect to FIG. 1. Failed ordinary packets also may be dropped or marked as non-conforming, possibly in conjunction with other processing.

Low priority policer 530, however, may be configured to “protect” premium packets from the high priority policer 520 based on their NPI value of 0. When the low priority policer 530 detects a “0” NPI bit, it may not perform “normal” policing. Rather, the low priority policer 530 may be configured to pass on the premium packets and remove an associated number of credits. In this manner, hierarchical policer 500 may ensure that the total traffic stays within bandwidth and burst size limits (e.g., 1 Mbps and 100 kb), while protecting premium packets by only dropping ordinary packets when these limits are exceeded.

Operation of Exemplary Policer

FIG. 6 is a flow chart illustrating operation of hierarchical policer 500 consistent with the principles of the invention. To begin, sorter 510 may set one or more NPI bits (e.g., to “1”) in a received packet [act 610]. Although FIG. 5 only shows one NPI bit, if sorter 510 has more than two levels of service, additional NPI bits may be used. Alternately, a single NPI bit may be used if the sorter 510 has a sequentially cascading design. Sorter 510 may also determine whether the packet is premium (i.e., high priority) or ordinary (i.e., low priority) and send it to an appropriate policer 520/530 [act 620].

If the packet is associated with a premium level of service, the high priority policer 520 may determine whether sufficient credit exists in its bucket to pass the packet [act 630]. If not, high priority policer 520 may drop the premium packet, because it exceeded the premium bandwidth and/or burst size constraints [act 640]. High priority policer 520 may also collect counts or other statistics on the dropped (or otherwise failed) packets.

If sufficient credit exists in the bucket of high priority policer 520, credit proportional to the size of the premium packet may be removed, the NPI bit(s) may be changed (e.g., from “1” to “0”), and the premium packet may be passed to low priority policer 530 [act 650].

Low priority policer 530 may check the state of the NPI bit(s) of an incoming packet to determine whether to perform normal policing or not [act 660]. If the NPI bit(s) are set (i.e., the packet is an ordinary packet), low priority policer 530 may begin normal policing and determine whether sufficient credit exists in its bucket to pass the packet [act 670]. If sufficient credit does not exist, low priority policer 530 may drop the packet, because it exceeded the total bandwidth and/or burst size constraints [act 640].

If sufficient credit exists for the packet with the set NPI bit(s), the low priority policer 530 may remove a proportional amount of credit from its bucket, and pass the packet to another element for further processing [act 680]. Because act 670 determined that sufficient credit was present, the bucket in the low priority policer 530 may be left with zero or more credits after the packet is passed on.

If the NPI bit(s) are determined not to be set (e.g., have a value of “0”) in act 660 (i.e., the packet is a premium packet in the example of FIG. 5), the low priority policer 530 still may remove a proportional amount of credit from its bucket, and pass the premium packet to another element for further processing [act 680]. Because act 670 is not performed for such packets with NPI=0, the low priority policer 530 does not really “police” such packets, and its operation is “modified” for the packets with NPI=0. In other words, if the packet has already been passed by a policer (e.g., 520), a subsequent policer may update the credit but not mark or drop the packet. In such a case, the bucket in the low priority policer 530 may start with zero or a small number of credits (because credits may not have been added since removal due to a previous packet), and the premium packet may cause the credits in the bucket of the low priority policer 530 to “go negative” (e.g., become a negative number).

With a “negative” number of credits, the low priority policer 530 will drop ordinary packets, but not premium packets, until its number of credits is sufficiently replenished. One alternative to using a negative value is to relax the maximum burst size (i.e., increase the bucket size) when NPI=0. For example, a maximum burst of 120 kb may be allowed when the packet is a premium packet. Another alternative to using a negative value would be to tighten the maximum burst size (i.e., decrease the bucket size) when NPI=0. For example, a maximum burst of 80 kb may be allowed when the packet is an ordinary packet. Either of these two schemes would allow a 20 kb premium packet to immediately follow a large ordinary packet without incurring a negative credit.

Note that the high priority policer 520 (or more generally an earlier policer than the last policer) may also check the NPI bit(s) to determine whether to perform normal policing in other implementations. In FIG. 5, however, there are no elements available before the high priority policer 520 to toggle the NPI bit(s) for premium packets, so the high priority policer 520 performs normal policing every time. If the NPI bit(s) are reset/modified (e.g., to “0”) in a packet by an earlier policer, however, all subsequent policers may perform “modified” processing on the packet, because the NPI bit(s), once reset, may remain so. Hence, the high priority policer 520 may be referred to more generically as an example of a “normal” policer, and the low priority policer 530 (and any subsequent policers) may be referred to more generically as an example of a “modified” policer which may perform normal policing or modified processing on a packet based on its NPI bit(s).

Software Implementation of Exemplary Policer

A hierarchical policer consistent with the principles of the invention may also be implemented via software, for example as a set of general instructions performed by a processor or one or more specific instructions performed by a special purpose processor. These instructions may be stored on a computer-readable medium, such as magnetic media, optical media, non-volatile memory (e.g., ROM), volatile memory (e.g., RAM), etc.

The overall policing described above may be performed using two exemplary software instructions, presented below in pseudo-code. The first, “normal policer” instruction is:

normal policer (bucket):
if (credit_avail ≧ packet_length) then
credit_avail = credit_avail − packet_length;
pass;
else
fail.

This normal policer instruction determines whether the length of a packet is greater than or equal to the credit available in a bucket (e.g., a number in a register). If so, the normal policer instruction subtracts credit proportional to the packet length from the credit available and passes the packet. If not, the normal policer instruction fails (e.g., drops) the packet. Although not explicitly shown, an associated “bucket” function may also track and update the credit available number according to predetermined service information (e.g., bandwidth and maximum burst size).

The second, “policer update” instruction is:

policer update (bucket):
credit_avail = credit_avail − packet_length;
pass.

This policer update instruction determines subtracts credit proportional to the packet length from the credit available and passes the packet, regardless of the amount of credit available. As with the normal policer instruction, an associated “bucket” function may also track and update the credit available number according to predetermined service information (e.g., bandwidth and maximum burst size).

Using these two instructions, the policing described in FIGS. 5 and 6 may be implemented in software as follows:

hierarchical policing ( ):
if (packet = premium) then
normal policer (high priority bucket);
if (pass) then
policer update (low priority bucket);
else
normal policer (low priority bucket).

As described in greater detail above, if the packet is a premium (e.g., high priority) packet, it may be processed with the normal policer instruction and the “high priority bucket” parameters. In the example herein, the high priority bucket parameters correspond to 200 kbps bandwidth and 20 kb maximum burst size.

If the premium packet passes (e.g., and has its NPI bit changed), it may be processed with the policer update instruction and the “low priority bucket” parameters. In the example herein, the low priority bucket parameters correspond to 1 Mbps bandwidth and 100 kb maximum burst size. The size of the premium packet may cause the credits available in the low priority bucket to be totally depleted or become negative. The low priority bucket function may track “negative” credits until the periodic addition of credits replenishes the credits in the low priority bucket.

If the packet is not a premium packet (i.e., it is ordinary or some lower service level), it may be processed with the normal policer instruction and the “low priority bucket” parameters. If there are insufficient credits for the ordinary packet (e.g., due to credit depletion by a premium packet), the ordinary packet may be failed (e.g., dropped) by the normal policer instruction.

CONCLUSION

As described above, a hierarchical policer may include multiple policers that either normally police traffic or pass the traffic without policing based on meta-data within units of the traffic. The meta-data data may be changed to affect subsequent processing of a unit of traffic after normal policing of that unit.

The foregoing description of preferred embodiments of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. Moreover, while a series of acts has been presented with respect to FIG. 6, the order of the acts may be different in other implementations consistent with principles of the invention. Additionally, lines with arrows are used in the figures to generally illustrate the flow of data. In practice, embodiments consistent with the principles of the invention may send data on these lines in both directions.

Further, it is specifically contemplated that the principles of the invention may be extended to hierarchical policers beyond the two-level policer described herein. Three or more levels of service may be implemented by a given configuration of policers, with some of the services sharing bandwidth and possibly other services not sharing bandwidth. Those skilled in the art will appreciate various parallel and serial configurations of policers (e.g., 520, 530) needed to implement differentiation between an arbitrary number of related service levels. Also, although token-bucket policers have been described, it is specifically envisioned that any other type of policer may be used in accordance with the principles of the invention.

Also, although traffic differentiation based bandwidth has been discussed, traffic policing may be performed using other characteristics of the traffic, such as various conforming flags, traffic origin, traffic protocol, etc. It should also be understood that within the bandwidth-limited example herein, the specific bandwidth and burst size numbers used are purely exemplary.

PFEs 210 may be implemented in hardware, software, or some combination thereof. For example, various portions of PFEs 210 may be implemented in application-specific integrated circuits (ASICs). The ASICs may be configured to perform some processing via dedicated logic, and may also be configured to perform some processing using microcode instructions that may be stored in memory. Those skilled in the router art will appreciate that the invention described herein might be practiced using a variety of hardware configurations in addition to, or instead of, ASICs. For example, some combination of general purpose processors, digital signal processors (DSPs), and programmable gate arrays (PGAs) may also be utilized to implement the functionality described herein.

No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used.

The scope of the invention is defined by the claims and their equivalents.

Claims

1-28. (canceled)

29. A device comprising:

a first component to: sort a plurality of packets; and

a second component to: receive one of the plurality of packets sorted by the first component of the device, pass, based on a first condition, the one of the plurality of packets to a third component of the device, and drop, based on a second condition, the one of the plurality of packets.

30. The device of claim 29, the first component further to:

set a bit of data of each of the plurality of packets to a first value; and

where the second component of the device is further to: change, based on the first condition, the bit of data of the one of the plurality of packets from the first value to a second, different value.

31. The device of claim 29, where each of the plurality of packets include a bit of data set to a common value, and

where the second component is further to: set the bit of data of the one of the plurality of packets to a different value.

32. The device of claim 31, where the first component is further to:

set the bit of data of each of the plurality of packets to the common value.

33. The device of claim 31, where the bit of data of each of the plurality of packets is set when a header of each of the plurality of packets is created.

34. The device of claim 31, where the third component is to:

receive the one of the plurality of packets from the second component of the device,

determine that the bit of the data of the one of the plurality of packets is set to the different value, and

pass, based on the bit of data of the one of the plurality of packets being set to the different value, the one of the plurality of packets.

35. The device of claim 29, where the third component is to:

pass, based on a third condition, the one of the plurality of packets received from the second component of the device.

36. A network device comprising:

a policer to: receive a first type of data from a sorter, pass, based on a first factor, the first type of data to another policer, drop, based on a second factor, the first type of data; and

the other policer to: receive a second type of data from the sorter, and receive, when passed by the policer, the first type of data from the policer.

37. The network device of claim 36, where the first type of data comprises data representing a first type of packet.

38. The network device of claim 37, where the data representing the first type of packet comprises a notification associated with the first type of packet.

39. The network device of claim 36, where each of the first and the second types of data include a bit of data,

where the sorter is to: set the bit of data of each of the first and the second types of data to a common value; and

where the policer is further to: change, prior to passing the first type of data, the bit of data of the first type of data to a different value.

40. The network device of claim 39, where the sorter is further to:

sort the first and the second types of data from a plurality of data received by the sorter, and

pass the second type of data to the other policer.

41. The network device of claim 40, where the other policer is further to:

police, based on a determination that the bit of data of the second type of data is set to the common value, the second type of data, and

pass, based on a determination that the bit of data of the first type of data received from the policer is set to the different value and without policing, the first type of data.

42. A method comprising:

sorting, by a first component of a device and based on a first condition, a plurality of packets including a first packet and a second packet;

receiving, by a second component of the device, the first packet from the first component of the device;

determining, by the second component of the device, whether the first packet meets a second condition;

determining, by the second component of the device and when the first packet is determined not to meet the second condition, whether the first packet meets a third condition;

passing, by the second component of the device and when the first packet meets the second condition, the first packet to a third component of the device; and

dropping, by the second component of the device and when the first packet meets the third condition, the first packet.

43. The method of claim 42, further comprising:

setting, by the first component of the device and prior to the receiving, a bit of data in the first packet and a corresponding bit of data in the second packet to a same value; and

setting, by the second component of the device and when the first packet meets the second condition, the bit of data in the first packet to a different value.

44. The method of claim 42, where a first bit of data in the first packet and a corresponding bit of data in the second packet are set to matching values, and

where the method further comprises: altering, by the second component of the device and when the first packet meets the second condition, the bit of data in the first packet.

45. The method of claim 42, further comprising:

receiving, by the third component of the device, a plurality of packets, the plurality of packets including the second packet from the first component of the device and the first packet from the second component of the device;

determining, by the third component, whether any of the plurality of packets comply with a fourth condition.

46. The method of claim 45, further comprising:

passing, by the third component and without policing, any of the plurality of packets determined to comply with the fourth condition.

47. The method of claim 46, further comprising:

determining, by the third component, whether any of the plurality of packets determined not to comply with the fourth condition comply with a fifth condition; and

passing, by the third component, any of the plurality of packets determined to comply with the fifth condition.

48. The method of claim 47, further comprising:

dropping, by the third component, any of the plurality of packets determined not to comply with the fourth and the fifth conditions.