Method and apparatus for flexible and efficient analytics in a network switch

METHOD AND APPARATUS FOR FLEXIBLE AND EFFICIENT ANALYTICS IN A NETWORK SWITCH

The present invention relates to traffic analysis within high-speed network switches. More specifically, the present invention relates to a method and apparatus for flexible and efficient analysis within a network switch, wherein the analysis includes counting, rate monitoring and flow sampling.

SDN (software defined networks) appeared, and open flow is one of the most representative ones. Incoming packets undergo a series of table search and matching operations, and analysis. Good abstraction in network switches is of paramount importance, as it not only simplifies programming at the next level, but also enables efficient use of limited hardware resources by changing requirements.

Counters, 2-rate 3-color rate monitors (policing) and flow sampling exist in prior art network switches. Prior art network switches use dedicated memory for each of these purposes. In particular, these counters, rate monitors and samplers are accessible from certain fixed stages of the inner pipeline because each processing unit of the inner pipeline is predefined to perform specified tasks. Counters are used to count the number of packets or bytes of traffic through a switch under various conditions. The policing classifies packets through the switch into three different colors: green, yellow or red, each color may be associated with a different quality of service (QoS). Sampling samples high-speed traffic flows into lower-speed streams and sends them to the system CPU for further processing or analysis. Thus, prior art network switches lack flexibility for counting, traffic rate monitoring and flow sampling.

Embodiments of the present invention relate to a centralized network analysis device, which efficiently uses on-chip memory to flexibly perform counting, traffic rate monitoring and flow sampling. The device includes a pool of memory shared by all cores and the packet processing stages of each core. Counting, monitoring and sampling are all defined through software allowing greater flexibility and efficient analysis within the device. In some embodiments, the device is a network switch.

In one aspect, a network switch is provided. A network switch includes at least one core that includes a plurality of pipeline stages. The network switch also includes a unified request and response interface for communicating with each of the plurality of pipeline stages of the at least one core to receive requests from the plurality of pipeline stages of the at least one core. Includes an interface module that includes The network switch is also coupled with the interface module and includes a common memory pool for processing the requests in parallel.

In some embodiments, the network switch further includes an analysis module to perform multiple parallel network analysis. The analysis module includes a plurality of client interfaces, an interconnect, and a plurality of analysis banks. The plurality of client interfaces and the plurality of analysis banks are interconnected through the interconnection unit.

In some embodiments, each of the plurality of client interfaces is programmable to map to one or more analysis banks of the plurality of analysis banks.

In some embodiments, memories from the common memory pool are divided into the plurality of analysis banks.

In some embodiments, the plurality of assay banks are homogenous.

In some embodiments, each of the plurality of analysis banks includes on-chip memory, such as a 272-bit wide and 512-entry deep on-chip memory.

In some embodiments, the plurality of client interfaces are similarly configured.

In some embodiments, each of the plurality of client interfaces includes a request interface for receiving requests and a response interface for sending responses. The request interface categorizes each request and determines a target analysis bank and a target entry address within the target analysis bank that the request should target. The target analysis bank is one of the plurality of analysis banks. The request is sent to the interconnect to be routed to the target analysis bank for processing.

In some embodiments, each of the plurality of client interfaces is configured as one of four modes: counter, polishing, polishing with billing counters, and sampling.

In some embodiments, the counting mode, the polishing mode and the sampling mode are each assigned a bank granularity, and the polishing mode with billing counters is assigned a granularity of a pair of analysis banks. For example, analysis bank 2*i is for polishing, and immediately following analysis bank 2*i+1 is for the corresponding billing counters.

In some embodiments, when the analysis bank is in counting mode, the analysis bank is configured in one of four configurations, and the correction operations are different for each of the configurations. The above modification operations are performed by 1 for each incoming request.<i>Events</i>An operation of incrementing the value of a field, by the value of the incoming request<i>Sum</i>an operation of incrementing the value of a field, and by the square of the value of the incoming request<i>sumOfSquare</i>Include an operation that increments the value of a field. The standard deviation of network activities is<i>sumOfSquare</i>from the average of<i>Sum</i>It is calculated by subtracting the square of the mean of The resulting response does not exit the analysis bank, and counter values are stored in the memory of the analysis bank. In some embodiments, the fifth configuration is used only for polishing mode with billing counter.

In some embodiments, when the analysis bank is in polishing mode, the analysis bank performs a 2-rate 3-color rate monitoring function. Every column of the analysis bank has one policer, and the policer has a configuration and an internal state. The policer returns the color of the packet to one of the client interfaces that originated the packet. In some embodiments, when the outgoing client interface is configured for a polishing mode with billing counters, the analysis bank sends a counter request to the next analysis bank to calculate the byte count for each packet of color.

In some embodiments, when the analysis bank is in sampling mode, the analysis bank supports N/M random sampling, and N consecutive events are sampled every M event intervals. A response is returned to the originating client interface for each request.

In another aspect, an assay bank is provided. The analysis bank includes at least three processing units and a memory bypass module.

The at least three processing units include a counter processing unit, a polishing processing unit and a sampling processing unit. The polishing processing unit may push a request to another analysis bank for byte counting of a color, wherein the another analysis bank is an analysis bank immediately following the analysis bank.

memory bypass module Hides memory read latency. In particular, output data of the memory bypass module is directed to the counter processing unit, the polishing processing unit or the sampling processing unit.

In some embodiments, when the analysis bank is in a counter mode, the counter processing unit is configured to calculate sums of squares, sums and event counts for network activity statistical analysis. In some embodiments, the counter processing unit is configured to calculate a standard deviation of network activities.

In another aspect, a network switching method is provided. The method involves partitioning a pool of shared memories into a plurality of homogeneous analysis banks, and programmable operation of each of the plurality of client interfaces in one of four modes: counter, polishing, polishing with billing counters, or sampling. It includes steps to make it possible. The method also includes programmatically mapping each of the plurality of client interfaces to a subset of the plurality of homogeneous analysis banks, and performing each of the plurality of homogeneous analysis banks in one of three modes: counter, polishing, or and allocating the program operation as one of the sampling. The method also includes parallel processing of multiple requests received at the plurality of client interfaces.

In some embodiments, processing the multiple requests in parallel includes determining, for each of the multiple requests, a target analysis bank and a target entry address within the target analysis bank.

Parallel processing of the multiple requests may include, when the target analysis bank is in the counter mode, the target analysis bank performing at least one of the following operations, such as a sum of squares, a summation, or an event count. include A standard deviation of network activities may also be calculated. Based on the target entry address a counter entry within the target analysis bank is determined and a memory column within the target analysis bank is determined to store counter values.

Processing multiple requests in parallel also includes performing, by the target analysis bank, a 2-rate 3-color rate monitoring function when the target analysis bank is in the polishing mode. The target analysis bank returns the packet's color to the packet's originating client interface. If configured as a policing with billing counters, the target analysis bank, when the target analysis bank is in the sampling mode, the target analysis bank, to the next analysis bank immediately to calculate the byte count for the packet of each color, Send counter request.

Parallel processing of multiple requests may also include, when the target analysis bank is in the sampling mode, the target analysis bank supporting random sampling N/M times, wherein N consecutive events occur every M times. Sampled at event intervals. The target analysis bank returns a response to the request's originating client interface.

The foregoing will become apparent from the following more specific description of exemplary embodiments of the present invention, as illustrated in the accompanying drawings, in which like reference numerals refer to like parts throughout the different drawings. The drawings are not necessarily drawn to scale, emphasis instead being emphasized when illustrating embodiments of the present invention. 1 illustrates an exemplary aspect of a network switch according to an embodiment of the present invention. 2 illustrates an analysis module according to an embodiment of the present invention. 3 illustrates a polishing analysis bank memory structure for a polishing mode with billing counters in accordance with an embodiment of the present invention. 4 illustrates a sampling analysis bank memory structure in accordance with an embodiment of the present invention. 5 illustrates a block diagram of an analysis bank in accordance with an embodiment of the present invention. 6 illustrates a method of a network switch according to an embodiment of the present invention.

In the following description, numerous details are mentioned for purposes of explanation. However, one skilled in the art will recognize that the present invention may be practiced without these specific details. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.

Embodiments of the present invention relate to a centralized network analysis device, which efficiently uses on-chip memory to flexibly perform counting, traffic rate monitoring and flow sampling. The device includes a pool of memory shared by all cores and the packet processing stages of each core. Counting, monitoring and sampling are all defined through software allowing greater flexibility and efficient analysis within the device. In some embodiments, the device is a network switch. Other networking devices are contemplated.

1 illustrates an exemplary aspect of a network switch 100 according to an embodiment of the present invention. Network switch 100 includes one or more cores 105 and a traffic manager 110. Each core 105 typically includes a plurality of pipeline stages. The plurality of pipeline stages include a plurality of packet processing units (115) and at least one packet modifier (120). All processing units 115, 120 within one or more cores 105 communicate with interface module 125 via a unified request and response interface (see FIG. 2). Interface module 125 is coupled to common memory pool 130 for request processing.

2 illustrates an analysis module 200 according to an embodiment of the present invention. Analysis module 200 is typically part of a network switch, such as network switch 100 of FIG. 1. The analysis module 200 includes a plurality of client interfaces 205, an interconnect 210 and a plurality of analysis banks 215. A plurality of client interfaces 205 and a plurality of analysis banks 215 are interconnected through an on-chip network 210. Each of the client interfaces 205 is programmable to map to one or more analysis banks of the plurality of analysis banks 215. Memories from common memory pool 130 of FIG. 1 are typically divided into a plurality of analysis banks 215. In some embodiments, the plurality of analysis banks 215 is homogenous, such that each analysis bank 215 contains the same number of memories as the other analysis banks 215. In some embodiments, each of the analysis banks 215 includes a 272-bit wide and 512-entry deep on-chip memory, although other memory sizes are possible.

In some embodiments, client interfaces 205 are similarly configured. Each client interface 205 typically has a request interface 205a and a response interface 205b. The request interfaces 205a of the client interfaces 205 are configured to receive incoming requests, each containing a request address and a request value, from the packet processing units, and the response interfaces 205b of the client interfaces 205) is configured to send responses to the packet processing units. In some embodiments, the packet processing units correspond to cores 105 of FIG. 1. Each of the request interfaces 205a typically classifies each incoming request and determines the target analysis bank and the target entry address within the target analysis bank that the request should target. The target analysis bank is typically one of one or more of the plurality of analysis banks 215 to which the client interface 205 is mapped. The request is then sent to the on-chip network 210 to be routed to the target analysis bank 215 for processing. Each request typically has no more than one response (e.g. no response or exactly one response).

Table 1 illustrates the table structure for each of the client interfaces 205. Each of the client interfaces 205:<i>mode</i>As indicated by the field, it can be configured in one of four possible modes (ie counting, polishing, polishing with billing counters, and sampling).

<tables num="1"><table><tgroup cols="3"><colspec colnum="1" align="center" colname="col1" colwidth="2790" /><colspec colnum="2" align="center" colname="col2" colwidth="2790" /><colspec colnum="3" align="center" colname="col3" colwidth="6038" /><tbody><row><entry align="center" namest="col1" nameend="col3"><b>Table 1</b></entry></row><row><entry align="center" colname="col1">Composition name</entry><entry align="center" colname="col2">size</entry><entry align="center" colname="col3">Explanation</entry></row><row><entry align="left" colname="col1">mode</entry><entry align="center" colname="col2">4</entry><entry align="left" colname="col3">Counting, polishing, polishing with billing counters, or sampling</entry></row><row><entry align="left" colname="col1">anaBankStart</entry><entry align="center" colname="col2">6</entry><entry align="left" colname="col3">Start Analysis Bank for Tables</entry></row><row><entry align="left" colname="col1">anaBankEnd</entry><entry align="center" colname="col2">6</entry><entry align="left" colname="col3">Analysis Bank End for Tables</entry></row><row><entry align="left" colname="col1">entryPerBank</entry><entry align="center" colname="col2">3</entry><entry align="left" colname="col3">512 - in units of entries. Used for address decoding of multi-bank tables. Each analysis bank may be configured to host a different amount of table entries.</entry></row></tbody></tgroup></table></tables>

As discussed above, if the sizes of the analysis banks 215 are the same, the connection between the client interfaces 205 and the analysis banks 215 is programmable through software. In particular, the mapping of each client interface 205 to a subset of the analysis banks 215 can be defined via software. At one extreme, the client interface 205 can use one analysis bank 215. At the opposite extreme, the client interface 205 can use all of the analysis banks 215. It is possible to use the same subset of analysis banks 215 for two or more client interfaces 205. Each client interface 205 is<i>anaBankStart</i>And<i>anaBankEnd</i>As specified in the fields, one or more analysis banks 215 may be utilized, and analysis banks 215 between fields are typically contiguous.<i>entryPerBank</i>A field represents a number of entries residing in each analysis bank 215.<i>entryPerBank</i>The field is used to calculate the target analysis bank 215 for each request. In some embodiments, analysis bank 215 (i.e.,<i>entryPerBank</i>The integer part of the incoming request address divided by the number of entries per.

In some embodiments, one or more pairs of analysis banks 215 are connected to a polishing mode with billing counters. That is, the counter mode, polishing mode and sampling mode are each assigned with bank granularity, but in the polishing mode with billing counters, analysis bank 2*i is for polishing and the next analysis bank 2*i+1 is for the corresponding billing counters. are assigned to the granularity of a pair of analysis banks 215 to be for

<i>counting</i>

Table 2 lists supported counting configurations of analysis bank 215 in counter mode. In counter mode, analysis bank 215 can be configured in one of four different configurations: A, B, C and D.

<tables num="2"><table><tgroup cols="4"><colspec colnum="1" align="left" colname="col1" colwidth="2497" /><colspec colnum="2" align="center" colname="col2" colwidth="2497" /><colspec colnum="3" align="center" colname="col3" colwidth="3014" /><colspec colnum="4" align="center" colname="col4" colwidth="3612" /><tbody><row><entry align="center" namest="col1" nameend="col4"><b>Table 2</b></entry></row><row><entry align="left" colname="col1"><b>mode</b></entry><entry align="center" colname="col2"><b>logical entry width</b></entry><entry align="center" colname="col3"><b>field</b></entry><entry align="center" colname="col4"><b>corrective action</b></entry></row><row><entry align="center" colname="col1">a</entry><entry align="left" colname="col2">136 beat</entry><entry align="left" colname="col3">54-b sumOfSquare</entry><entry align="left" colname="col4">sumOfSquare += value²</entry></row><row><entry align="center" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">46-b sum</entry><entry align="left" colname="col4">sum += value</entry></row><row><entry align="center" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">36-b events</entry><entry align="left" colname="col4">events += 1</entry></row><row><entry align="center" colname="col1">B</entry><entry align="left" colname="col2">68 beat</entry><entry align="left" colname="col3">38-b sum</entry><entry align="left" colname="col4">sum += value</entry></row><row><entry align="center" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">30-b events</entry><entry align="left" colname="col4">events += 1</entry></row><row><entry align="center" colname="col1">C</entry><entry align="left" colname="col2">34 beat</entry><entry align="left" colname="col3">34-b events</entry><entry align="left" colname="col4">events += 1</entry></row><row><entry align="center" colname="col1">d</entry><entry align="left" colname="col2">17 beat</entry><entry align="left" colname="col3">17-b events</entry><entry align="left" colname="col4">events += 1</entry></row><row><entry align="center" colname="col1">P</entry><entry align="left" colname="col2">246 beat</entry><entry align="left" colname="col3">46-b red_sum</entry><entry align="left" colname="col4"></entry></row><row><entry align="left" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">36-b red_events</entry><entry align="left" colname="col4"></entry></row><row><entry align="center" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">46-b yellow_sum</entry><entry align="left" colname="col4"></entry></row><row><entry align="left" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">36-b yellow_events</entry><entry align="left" colname="col4"></entry></row><row><entry align="left" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">46-b green_sum</entry><entry align="left" colname="col4"></entry></row><row><entry align="left" colname="col1"></entry><entry align="left" colname="col2"></entry><entry align="left" colname="col3">36-b green_events</entry><entry align="left" colname="col4"></entry></row></tbody></tgroup></table></tables>

Modification operations are different for each of the counter mode configurations. In counter mode configuration A, a counter entry has three fields:<i>sumOfSquare</i>, <i>Sum</i>And<i>Events</i>Includes.<i>Events</i>The value of the field is incremented by 1 for each incoming request.<i>Sum</i>The value of the field is incremented by the value of the incoming request.<i>sumOfSquare</i>The field is incremented by the square of the value of the incoming request. In this way, higher level applications<i>sumOfSquare</i>mean of (<i>sumOfSquare</i>/<i>Events</i>) from<i>Sum</i>(In other words,<i>Sum</i>/<i>Events</i>) can be used to derive the standard deviation by subtracting the square of the mean. The standard deviation allows for additional statistical analysis of network switches. Counter mode configurations B, C, D and P are organized similarly to counter mode configuration A. In some embodiments, the counter mode configuration P is used only for policing with billing counters, and thus is not visible to the client interfaces 205 of FIG. 2. Polishing with billing counters is discussed below.

As shown in Table 2, each counter entry is smaller than the memory width. The least significant bit of the target entry address is used to select a counter entry within memory, while the most significant bit is used to select a memory string within an analysis bank. Normally there is no resulting response for counter mode. That is, no response is output from the analysis bank. Rather, the counter values are stored in the memory of the analysis bank to the system CPU for reading.

Based on the configuration of the analysis banks, each of the fields will continue or wrap around the maximum value of the field.

<i>polishing</i>

Each of the analysis banks 215 of FIG. 2 can be configured as a 2-rate 3-color marking polishing analysis bank to perform a standard 2-rate 3-color rate monitoring function. Every row in the polishing analysis bank has 1 policer or rate monitor. The terms policer and rate monitor are used interchangeably herein. The policer classifies each packet as one of three colors: red, yellow, and green. A packet is marked red if it exceeds the peak rate. Otherwise, the packet is marked yellow or green depending on whether the packet exceeds or does not exceed the agreed upon rate.

Each policer has its own configuration and internal state. Typically, internal state is in the upper half of the policer, and configuration is in the lower half of the policer. Configuration typically includes 2 rates, and state typically includes what the current state is. The policer returns the color of the packet to the originating client interface.

Polishing with billing counters includes an even number of analysis banks, where analysis bank 2*i is for the policing and analysis bank 2*i+1 is for the associated billing counters. 3 illustrates a polishing analysis bank memory structure 300 for a polishing mode with billing counters in accordance with an embodiment of the present invention. As shown in FIG. 3, when the outgoing client interface is configured as a polishing mode with billing counters, an analysis bank 305 configured in the polishing mode counters to the next analysis bank 310 configured in its counter mode configuration P. send the request As such, the byte count for each packet of color is calculated in the analysis bank 310.

<i>sampling</i>

Table 3 lists the supported sampling configurations of analysis bank 215 in sampler mode. Each of the analysis banks 215 is configured to support N/M random sampling, where N consecutive events are sampled every M events interval. At each interval, the sampled events start from a random offset. In this mode, each sampler has an associated configuration, as shown in Table 3. M is M_base*2^M_expoIs calculated as

<tables num="3"><table><tgroup cols="3"><colspec colnum="1" align="left" colname="col1" colwidth="2933" /><colspec colnum="2" align="center" colname="col2" colwidth="2933" /><colspec colnum="3" align="center" colname="col3" colwidth="5753" /><tbody><row><entry align="center" namest="col1" nameend="col3"><b>Table 3</b></entry></row><row><entry align="left" colname="col1">field</entry><entry align="center" colname="col2">width</entry><entry align="center" colname="col3">Explanation</entry></row><row><entry align="left" colname="col1">n</entry><entry align="center" colname="col2">8</entry><entry align="left" colname="col3"></entry></row><row><entry align="left" colname="col1">M_base</entry><entry align="center" colname="col2">8</entry><entry align="left" colname="col3">M = M_base * 2^M_expo, M is 255*2¹²becomes the maximum value in</entry></row><row><entry align="left" colname="col1">M_expo</entry><entry align="center" colname="col2">4</entry><entry align="left" colname="col3"></entry></row><row><entry align="left" colname="col1">sub Total</entry><entry align="center" colname="col2">20</entry><entry align="left" colname="col3"></entry></row></tbody></tgroup></table></tables>

Table 4 illustrates the sampler states for each individual sampler in the analysis bank.

<tables num="4"><table><tgroup cols="3"><colspec colnum="1" align="left" colname="col1" colwidth="2933" /><colspec colnum="2" align="center" colname="col2" colwidth="2933" /><colspec colnum="3" align="center" colname="col3" colwidth="5753" /><tbody><row><entry align="center" namest="col1" nameend="col3"><b>Table 4</b></entry></row><row><entry align="left" colname="col1">field</entry><entry align="center" colname="col2">width</entry><entry align="center" colname="col3">Explanation</entry></row><row><entry align="left" colname="col1">total_cnt</entry><entry align="center" colname="col2">64</entry><entry align="left" colname="col3">Total events that could have been sampled</entry></row><row><entry align="left" colname="col1">interval_event_cnt</entry><entry align="center" colname="col2">20</entry><entry align="left" colname="col3">Wraparound in M, independent of clearOnRead and/or wraparound configuration</entry></row><row><entry align="left" colname="col1">interval_smp_start</entry><entry align="center" colname="col2">20</entry><entry align="left" colname="col3">Event to start sampling from, updated every N events</entry></row><row><entry align="left" colname="col1">sub Total</entry><entry align="center" colname="col2">104</entry><entry align="left" colname="col3"></entry></row></tbody></tgroup></table></tables>

As shown in Table 4,<i>total_cnt</i>The field records the total number of sampled events.<i>total_cnt</i>Fields are read and cleared from the CPU to allow the system to obtain important statistics about the sampler. this field is also<i>interval_event_cnt</i>At the beginning of each interval, hold an intermediate state to count the start and end of the current sampling interval, and the random sampling start point is the events<i>interval_smp_start</i>To<i>interval_smp_start</i>+N-1 is determined to be sampled. For each request, a sampled or non-sampled response is returned to the originating client interface.

4 illustrates a sampling analysis bank memory structure 400 according to one embodiment of the present invention. As shown in Figure 4, two sample entries reside on a memory column, the least significant bit of the target entry address is used to select one of these two entries, and all other bits are used to select the target memory column..

<i>analysis bank</i>

5 illustrates a block diagram of an analysis bank 500 according to an embodiment of the present invention. Analysis bank 500 is configured similarly to analysis bank 215. All operations for counters, polishing and sampling can be categorized as memory read-modify-write. For memories, there can be read latency, which can create a hazard, so the memory bypass module 505 is used to mask the memory read latency. The output data of memory bypass module 505 is directed to one of three processing units: counter processing unit 520, polishing processing unit 510 or sampling processing unit 515. As discussed above, the polishing processing unit 510 can push a request to the very next analysis bank (not shown) for byte counting of each color.

6 illustrates a method 600 of a network switch, such as network switch 100 of FIG. 1, in accordance with an embodiment of the present invention. As discussed above, the network switch 100 includes an interface module and a pool of shared memories. An interface module typically includes a plurality of client interfaces. Each of the client interfaces includes a request interface for receiving requests and a response interface for sending responses.

At step 605, the pool of shared memories is partitioned into a plurality of homogeneous analysis banks. In some embodiments, each of the homogeneous analysis banks includes a 272-bit wide and 512-entry deep on-chip memory.

At step 610, each of the plurality of client interfaces is configured to be programmable in one of four modes: counting, polishing, polishing with billing counters, or sampling.

At step 615, each of the plurality of client interfaces is programmatically mapped to a subset of the plurality of homogeneous analysis banks. At one extreme, the client interface is mapped to a single analysis bank. At the opposite extreme, the client interface maps to all analysis banks.

At step 620, each of the plurality of homogeneous analysis banks is assigned programmable operation in one of three modes: counter, polishing, or sampling.

At step 625, multiple requests received at the plurality of client interfaces are processed in parallel. For each of the multiple requests, a target analysis bank and a target entry address within the target analysis bank are determined.

When the target analysis bank is in counter mode, the target analysis bank performs at least one operation, such as sum of squares or sum of event counts. A standard deviation of network activities may also be calculated. A counter entry in the target analysis bank is determined based on the target entry address. A memory column within the target analysis bank is also determined to store counter values.

When the target analysis bank is in the polishing mode, the target analysis bank performs a 2-rate 3-color rate monitoring function. The target analysis bank returns the packet's color to the packet's originating client interface. When the outgoing client interface is configured as a policing with billing counters, the target analysis bank sends a counter request to the next analysis bank to calculate the byte count for each packet of the color.

When the target analysis bank is in sampling mode, the target analysis bank supports N/M random sampling, and N consecutive events are sampled every M events. The target analysis bank returns a response to the request's originating client interface.

The network switch of the present invention differs from the prior art in that the counter module, the policing module, the sampling module or all are fixed to a specific processing unit. Contrary to the prior art, counting, monitoring and sampling are all defined or programmed through software allowing greater flexibility and efficient analysis within the network switch of the present invention.

One skilled in the art will recognize that other uses and advantages also exist. Although the invention has been described with reference to numerous specific details, those skilled in the art will recognize that the invention may be embodied in other specific forms without departing from its spirit. Accordingly, those skilled in the art will understand that the present invention is not limited to the foregoing illustrative details, but rather is defined by the appended claims.