Patent Description:
A network element typically stores incoming packets for processing and forwarding. Storing the packets in a shared buffer enables to share storage resources efficiently. Methods for managing shared buffer resources are known in the art. For example, <CIT> describes a communication apparatus that includes multiple interfaces configured to be connected to a packet data network for receiving and forwarding of data packets of multiple types. A memory is coupled to the interfaces and configured as a buffer to contain packets received through the ingress interfaces while awaiting transmission to the network via the egress interfaces. Packet processing logic is configured to maintain multiple transmit queues, which are associated with respective ones of the egress interfaces, and to place both first and second queue entries, corresponding to first and second data packets of the first and second types, respectively, in a common transmit queue for transmission through a given egress interface, while allocating respective spaces in the buffer to store the first and second data packets against separate, first and second buffer allocations, which are respectively assigned to the first and second types of the data packets.

<CIT> relates to a per-flow dynamic buffer management scheme for a data communications device. With per-flow dynamic buffer limiting, the header information for each packet is mapped into an entry in a flow table, with a separate flow table provided for each output queue. Each flow table entry maintains a buffer count for the packets currently in the queue for each flow. On each packet enqueuing action, a dynamic buffer limit is computed for the flow and compared against the buffer count already used by the flow to make a mark, drop, or enqueue decision. A packet in a flow is dropped or marked if the buffer count is above the limit. Otherwise, the packet is enqueued and the buffer count incremented by the amount used by the newly-enqueued packet.

<CIT> relates to a communication apparatus including multiple interfaces connected to a packet data network and at least one memory configured as a buffer to contain packets received through the ingress interfaces while awaiting transmission to the network via respective egress interfaces. Processing circuitry is configured to identify data flows to which the data packets that are received through the ingress interfaces belong, to assess respective bandwidth characteristics of the data flows, and to select one or more of the data flows as candidate flows for mirroring responsively to the respective bandwidth characteristics. The processing circuitry selects, responsively to one or more predefined mirroring criteria, one or more of the data packets in the candidate flows for analysis by a network manager, and sends the selected data packets to the network manager over the network via one of the egress interfaces.

The present invention is disclosed in the independent claims. The dependent claims define particular embodiments of the invention.

Embodiments that are described herein provide methods and systems for flow-based management of shared buffer resources.

A shared buffer in a network element stores incoming packets that typically belong to multiple flows. The stored packets are processed and await transmission to their appropriate destinations.

The storage space of the shared buffer is used for storing packets received via multiple ingress ports and destined to be delivered via multiple egress ports. In some embodiments, a shared buffer controller manages the shared buffer for achieving fair allocation of the storage space among ports.

In some embodiments, the shared buffer controller manages the shared buffer resources by allocating limited amounts of storage space to entities referred to herein as "regions. " A region may be assigned to a pair comprising an ingress port and a reception priority, or to a pair comprising an egress port and a transmission priority. For each region, the shared buffer stores data up to a respective threshold that is adapted dynamically.

The shared buffer performs accounting of the amount of data currently buffered per each region and decides to admit a received packet into the shared buffer or to drop the packet, based on the accounting. In this scheme, the decision of packet admission is related to ingress/egress ports and to reception/transmission priorities but does not take into consideration the flows to which the packets traversing the network element belong.

In the disclosed embodiments, for enhancing the flexibility in managing the shared buffer storage space, a new type of a region is specified, which is referred to herein as a "flow-based" region. A flow-based region corresponds to a specific flow but is independent of any ports and the priorities assigned to ports. Using flow-based regions provides a flow-based view of the shared buffer usage, and therefore can be used for prioritizing different data flows in sharing the storage space. Moreover, complex admission schemes that combine several flow-based regions or combine a flow-based region with a port/priority region can also be used.

Consider a network element comprising multiple ports, a memory configured as a Shared Buffer (SB), a SB controller and data-plane logic. The multiple ports are configured to connect to a communication network. The Shared Buffer (SB) is configured to store packets received from the communication network. The SB controller is configured to perform flow-based accounting of packets received by the network element for producing flow-based data counts, each flow-based data count associated with one or more respective flows, and to generate admission states based at least on the flow-based data counts, each admission state is generated from one or more respective flow-based data counts. The data-plane logic is configured to receive a packet from an ingress port, to classify the packet into a respective flow, and based on one or more admission states that were generated based on the flow-based data counts, to decide whether to admit the packet into the SB or drop the packet.

The SB controller may manage the data counts and admission states in various ways. In an embodiment, the SB controller produces an aggregated data count for packets belonging to multiple different flows, and generates an admission state for the packets of the multiple different flows based on the aggregated data count. In another embodiment, the SB controller produces first and second flow-based data counts for packets belonging to respective first and second different flows, generates an admission state for the packets of the first and second flows based on both the first and the second flow-based data counts. In yet another embodiments, the SB controller generates multiple admission states based on multiple selected flows, and the data-plane logic decides whether to admit a packet belonging to one of the selected flows into the SB or drop the packet, based on the multiple admission states.

In processing the received packets, the data-plane logic determines for the received packets respective egress ports, ingress priorities and egress priorities. The SB controller performs occupancy accounting for (i) Rx data counts associated with respective ingress ports and ingress priorities, and (ii) Tx data counts associated with respective egress ports and egress priorities. The SB controller generates the admission states based on the flow-based data counts and on at least one of the Rx data counts and the Tx data counts. Note that the SB controller performs the flow-based accounting and the occupancy accounting in parallel.

The SB controller may link a received packet to a flow-based data count in various ways. In some embodiments, the SB controller identifies for a received packet a corresponding flow-based data count by (i) applying a hash function to one or more fields in a header of the received packet, or (ii) processing the packet using an Access Control List (ACL). In other embodiments, the SB controller identifies for a received packet a corresponding flow-based data count based on flow-based binding used in a protocol, such as, for example, a tenant protocol, a bridging protocol, a routing protocol or a tunneling protocol.

The flow-based accounting that is used for managing the SB resources may be used for other purposes such as flow-based mirroring and flow-based congestion avoidance, as will be described further below.

In the disclosed techniques a SB controller performs flow-based accounting for selected flows. This allows sharing storage space based on individual flow prioritization. This flow-based view enables fair sharing of storage space among competing flows, regardless of the ports via which the flows arrive at the network element. Moreover, flexible admission schemes that combine flow-based data counts and occupancy data counts are also possible.

<FIG> is a block diagram that schematically illustrates a network element <NUM> handling flow-based packet admission in a shared buffer, in accordance with an embodiment that is described herein.

In the description that follows and in the claims, the term "network element" refers to any device in a packet network that communicates packets with other devices in the network, and/or with network nodes coupled to the network. A network element may comprise, for example, a switch, a router, or a network adapter.

Network element <NUM> comprises interfaces in the form of ingress ports <NUM> and egress ports <NUM> for connecting to a communication network <NUM>. Network element <NUM> receives packets from the communication network via ingress ports <NUM> and transmits forwarded packets via egress ports <NUM>. Although in <FIG>, the ingress ports and egress ports are separated, in practice, each port may serve as both an ingress port and an egress port.

Communication network <NUM> may comprise any suitable packet network operating using any suitable communication protocols. For example, communication network <NUM> may comprise an Ethernet network, an IP network or an InfiniBand™ network.

Each ingress port <NUM> is associated with respective control logic <NUM> that processes incoming packets as will be described below. Although in <FIG> only two control logic modules are depicted, a practical network element may comprise hundreds ingress ports and corresponding control logic modules. A memory <NUM>, coupled to ports <NUM>, is configured as a shared buffer for temporarily storing packets that are processed and assigned to multiple queues for transmission to the communication network.

Upon receiving an incoming packet via an ingress port <NUM>, the ingress port places the packet in shared buffer <NUM> and notifies relevant control logic <NUM> that the packet is ready for processing. A parser <NUM> parses the packet header(s) and generates for the packet a descriptor, which the parser passes to a descriptor processor <NUM> for further handling and generation of forwarding instructions. Based on the descriptor, descriptor processor <NUM> typically determines an egress port <NUM> through which the packet is to be transmitted. The descriptor may also indicate the quality of service (QoS) to be applied to the packet, i.e., the level of priority at reception and for transmission, and any applicable instructions for modification of the packet header. An admission decision module <NUM> decides on whether to drop or admit the packet. The admission decision module determines the admission decision based on admission states <NUM>, as will be described in detail bellow.

Descriptor processor <NUM> places the descriptors of admitted packets in the appropriate queues in a queueing system <NUM> to await transmission via the designated egress ports <NUM>. Typically, queuing system <NUM> contains a dedicated queue for each egress port <NUM> or multiple queues per egress port, one for each QoS level (e.g., transmission priority).

Descriptor processor <NUM> passes the descriptors of admitted packets to queueing system <NUM> and to a buffer (SB) controller <NUM>, which serves as the central buffer management and accounting module for shared buffer <NUM>. SB controller <NUM> performs two types of accounting, referred to herein as "occupancy accounting" and "flow-based accounting. " For the occupancy accounting, the SB controller manages "occupancy data counts" <NUM>, whereas for the flow-based accounting, the SB controller manages "flow-based data counts" <NUM>. SB controller <NUM> receives consumption information in response to control logic <NUM> deciding to admit a packet, and receives release information in response to transmitting a queued packet. SB controller <NUM> increments or decrements the occupancy data counts and the flow-based data counts, based on the consumption and release information.

The SB controller may manage the occupancy data counts and the flow-based data counts using any suitable count units, such as numbers of bytes or packets. Based on flow-based data counts <NUM> and possibly on occupancy data counts <NUM>, SB controller produces admission states <NUM> to be used by admission decision modules <NUM> for deciding on admission/drop for each received packet.

In some embodiments, SB controller <NUM> that manages flow-based data counts as well as occupancy data counts in association with entities that referred to herein as "regions. " An occupancy region comprises a pair of an ingress port and Rx priority or a pair of an egress port and a Tx priority. A flow-based region comprises a flow. The SB controller may determine admission states <NUM> based on pools <NUM>, wherein each pool is associated with multiple regions or with their corresponding data counts. For example, a pool comprises one or more flow-based data counts, and possibly one or more Rx occupancy data counts and/or one or more Tx occupancy data counts.

In some embodiments, SB controller <NUM> comprises an interface <NUM>, via which the SB controller accesses occupancy data counts <NUM>, flow-based data counts <NUM>, and admission states <NUM>. In an embodiment, interface <NUM> serves also for accessing consumption and release information by the SB controller.

When a descriptor of a packet queued in queueing system <NUM> reaches the head of its queue, queuing system <NUM> passes the descriptor to a packet transmitter <NUM> for execution. Packet transmitters <NUM> are respectively coupled to egress ports <NUM> and serve as packet transmission modules. In response to the descriptor, packet transmitter <NUM> reads the packet data from shared buffer <NUM>, and (optionally) makes whatever changes are called for in the packet header for transmission to communication network <NUM> through egress port <NUM>.

Upon the transmission of the packet through the corresponding egress port <NUM>, packet transmitter <NUM> signals SB controller <NUM> that the packet has been transmitted, and in response, SB controller <NUM> releases the packet from SB <NUM>, so that the packet location in SB <NUM> can be overwritten. This memory accounting and management process typically takes place for multiple different packets in parallel at any given time.

The configuration of network element <NUM> in <FIG>, is given by way of example, and other suitable network element configurations can also be used.

Some elements of network element <NUM>, such as control logic <NUM> and SB controller <NUM> may be implemented in hardware, e.g., in one or more Application-Specific Integrated Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs). Additionally or alternatively, some elements of the network element can be implemented using software, or using a combination of hardware and software elements.

Elements that are not necessary for understanding the principles of the present application, such as various interfaces, addressing circuits, timing and sequencing circuits and debugging circuits, have been omitted from <FIG> for clarity.

Memory <NUM> may comprise any suitable storage device using any suitable storage technology, such as, for example, a Random Access Memory (RAM). The SB may be implemented in an on-chip internal RAM or in an off-chip external RAM.

In some embodiments, the SB controller is comprised in any suitable apparatus such as a network element or a Network Interface Controller (NIC). In some embodiments, the SB is comprised in a memory accessible to the SB controller, the memory being external to the apparatus. In other embodiments, the apparatus further comprises a memory, and the SB is comprised in the memory.

In some embodiments, some of the functions of SB controller <NUM> may be carried out by a general-purpose processor, which is programmed in software to carry out the functions described herein. The software may be downloaded to the processor in electronic form, over a network, for example, or it may, alternatively or additionally, be provided and/or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory.

In the description that follows and in the claims, elements involved in real-time packet processing and forwarding for transmission are collectively referred to as "data-plane logic. " In the example of <FIG>, the data-plane logic for processing a given packet comprises ingress port <NUM>, control logic <NUM>, queueing system <NUM>, packet Tx <NUM> and egress port <NUM>. The data-plane logic does not include control processing tasks such as generating admission states <NUM> by SB controller <NUM>.

In some embodiments, SB controller <NUM> manages SB <NUM> for achieving a fair usage of the shared buffer. To this end, regions corresponding to (PI,Rp) and (PO,Tp) are allocated respective storage spaces in the shared buffer. In the regions above, PI and PO denote respective ingress and egress ports, and Rp and Tp denote respective reception and transmission priorities. The allocated storage spaces are bounded to respective dynamic thresholds. The SB controller holds the amount of data consumed at any given time by regions (PI,Rp) and (PO,Tp) in respective occupancy data counts <NUM>.

In some disclosed embodiments, the SB controller manages the SB resources using a flow-based approach. In these embodiments, the SB manages flow-based regions associated with flow-based data counts <NUM>. Each flow-based region virtually consumes a storage space of the shared buffer bounded to a dynamic threshold. A flow-based view of SB storage consumption can be used for prioritizing SB storage among different data flows.

Admission states <NUM> are indicative of the amount of data consumed relative to corresponding dynamic thresholds. An admission state may have a binary value that indicates whether a data count exceeds a relevant dynamic threshold, in which case the packet should be dropped. Alternatively, an admission state may have multiple discrete values or a contiguous range, e.g., an occupancy percentage of the bounded storage space.

A packet tested by admission decision module <NUM> for admission may be linked to one or more regions (or corresponding data counts). For example, the packet may be linked to an occupancy data count of a region (PI, Rp), to an occupancy data count of a region (PO, Tp), and/or to a flow-based data count of a flow-based region. In general, a packet may be linked to at least one of the data count types (i) flow-based data count (ii) Rx occupancy data count, and (iii) Tx occupancy data count. Each data count type may be associated with a pool <NUM>, depending on the SB configuration. A packet linked to a pool of multiple data counts is also associated with one or more admission states that SB controller <NUM> determines based on the multiple data counts.

A packet may be linked or bound to a certain data count or to a pool of multiple data counts in various ways, as described herein. In some embodiments, SB controller <NUM> identifies a data count (or a pool) corresponding to a received packet, e.g., a flow-based data count, by applying a hash function to one or more fields in a header of the received packet resulting in an identifier of the pool. In another embodiment, the SB controller identifies a data count (or a pool) corresponding to a received packet by processing the received packet using an Access Control List (ACL) that extracts the pool identifier.

In some embodiments, the SB controller identifies for a received packet corresponding data counts (e.g., flow-based data count) based on flow-based binding used in a protocol selected from a list of protocols comprising: a tenant protocol, a bridging protocol, a routing protocol and a tunneling protocol. In these embodiments, the flow to which the packet belongs represents the selected protocol.

Decision module <NUM> may decide on packet admission or drop, based on multiple admission states, in various ways. For example, when using binary admission states, decision module <NUM> may decide to admit a packet only when all the relevant admission states are indicative of packet admission. Alternatively, SB controller <NUM> may decide on packet admission when only part of the relevant admission states are indicative of packet admission, e.g., based on a majority vote criterion.

In some embodiments, the values of the admission states comprise a contiguous range, and the decision module decides on packet admission by calculating a predefined function over some or all of the relevant admission states. For example, the SB controller calculates an average data count based on two or more selected data counts, and determines the admission state by comparing the average data count to the dynamic threshold.

<FIG> are diagrams that schematically illustrate example flow-based admission configurations, in accordance with embodiments that are described herein.

In general, accounting and generating admission states are tasks related to control-plane processing, whereas admission decision is a task related to the data-plane processing. The flow-based admission configurations will be described as executed by network element <NUM> of <FIG>.

<FIG> depicts a processing flow <NUM> in which packet admission is based on a single flow denoted FL1. Packets <NUM> belonging to flow FL1 are received via an ingress port <NUM>, which places the packets in SB <NUM>. Typically, packets of flows other than FL1 are also received via the same ingress port as the packets of FL1. The packets received via ingress port <NUM> are processed by a respective control logic module <NUM>.

In performing accounting, SB controller <NUM> receives consumption information indicative of admitted packets, and release information indicative of transmitted packets. SB controller <NUM> performs flow-based accounting to the FL1 packets to produce a flow-based data count denoted FB_DC1. In some embodiments, based on the consumption and release information, SB controller <NUM> performs occupancy-based accounting to produce occupancy data counts <NUM>, depending on ingress ports, egress ports and Rx/Tx priorities determined from packets' headers. This accounting is part of the control-plane tasks.

SB controller <NUM> produces for the packets of FL1, based on FB_DC1, an admission state <NUM>, denoted AS1. In the example of <FIG>, SB controller <NUM> also produces, based on occupancy data counts <NUM>, occupancy admission states <NUM>, including Rx admission states denoted RxAS, and Tx admission states denoted TxAS. Occupancy data counts <NUM> and admission states <NUM> are not related to any specific flow.

In deciding on packet admission, admission decision module <NUM> produces respective admission decisions <NUM> for the packets of flow FL1. The admission decisions may be based, for example, on the flow-based admission state AS1 alone, or on one or more of occupancy admission states <NUM> in addition to AS1.

In some embodiments, SB controller <NUM> comprises a visibility engine <NUM> that monitors flow-based data counts such as FB_DC1. Visibility engine <NUM> generates a visibility indication based on the behavior of FB_DC1. For example, the visibility indication may be indicative of a short-time change in the value of the flow-based data count. In some embodiments, admission decision module <NUM> may produce admission decisions <NUM> based also on the visibility indication. In some embodiments, visibility engine <NUM> produces a visibility indication that is used for flow-based mirroring, as will be described below.

Control logic <NUM> passes descriptors of packets belonging to FL1 for which the admission decision is positive to queueing system <NUM>, for transmission to the communication network, using packet TX <NUM>, via an egress port <NUM>. Control logic <NUM> reports packets of FL1 that have been dropped to the SB controller, which releases the dropped packets from SB <NUM>.

<FIG>, depicts a processing flow <NUM> in which packet admission is based on two different flows denoted FL2 and FL3. Packets <NUM> belonging to FL2 and packets <NUM> belonging to FL3 are received via an ingress port <NUM> (or via two different ingress ports <NUM>) and placed in SB <NUM>. Note that packets received via different ingress ports are processed using different respective control logic module <NUM>.

In the present example, in performing accounting, SB controller <NUM> performs aggregated flow-based accounting for the packets of both FL2 and FL3 to produce a common flow-based data count <NUM> denoted FB_DC2. The flow-based data count FB_DC2 is indicative of the amount of data currently buffered in the network element from both FL2 and FL3.

SB controller <NUM> produces for the packets of FL2 and FL3, based on FB_DC2, an admission state <NUM>, denoted AS2. In the example of <FIG>, SB controller <NUM> also produces, based on the occupancy data counts, occupancy admission states <NUM> (similarly to admission states <NUM> of <FIG>).

In deciding on admission, admission decision modules <NUM> in control logic modules <NUM> that process packets of FL2 and FL3, produce admission decisions <NUM> for the packets of both FL2 and FL3. The admission decisions may be based, for example, on flow-based admission state AS2 alone, or on AS2 and on one or more of occupancy admission states <NUM>.

In some embodiments, a visibility engine <NUM> (similar to visibility engine <NUM> above) monitors FB_DC2 and outputs a visibility indication based on FB_DC2. Admission decision module <NUM> may use the visibility indication in producing admission decisions <NUM>.

Control logic modules <NUM> that process packets of FL2 and FL3, pass descriptors of packets belonging to these flows that have been admitted to queueing system <NUM>, for transmission using packet Tx <NUM> via a common egress port <NUM> or via two respective egress ports. Control logic modules <NUM> that process packets of FL2 and FL3, report packets of FL2 and FL3 that have been dropped to the SB controller, which releases the dropped packets from SB <NUM>.

<FIG>, depicts a processing flow <NUM> for packet admission based on three different flows denoted FL4, FL5 and FL6. Packets <NUM>, <NUM> and <NUM> belonging to respective flows FL4, FL5 and FL6 are received via one or more ingress ports <NUM> and placed in SB <NUM>.

In the present example, in performing accounting, SB controller <NUM> performs separate flow-based accounting to packets of FL4, FL5 and FL6, to produce respective flow-based data counts <NUM> denoted FB_DC3, FB_DC4 and FB_DC5.

In the present example, SB controller <NUM> produces, based on data counts FB_DC3, FB_DC4 and FB_DC5 two admission states <NUM> denoted AS3 and AS4. Specifically, SB controller <NUM> produces AS3 based on data counts FB_DC3 and FB_DC4 corresponding to FL4 and FL5, and produces, AS4 based on a single data count FB_DC5 corresponding to FL6. In some embodiments, SB controller <NUM> also produces, based on the occupancy data counts, occupancy admission states <NUM> (similarly to admission states <NUM> of <FIG>).

In deciding on admission, admission decision modules <NUM> of control logic modules <NUM> that process packets of FL4, FL5 and FL6 produce admission decisions <NUM> for the packets of flows FL4, FL5 and FL6, based at least on one of flow-based admission states AS3 and AS4. In an embodiment, the admission decision is also based on one or more of occupancy admission states <NUM>.

In some embodiments, the admission decisions may be additionally based on one or more visibility indications <NUM> produced by monitoring one or more of flow-based data counts FB_DC3, FB_DC4 and FB_DC5 using visibility engine(s) (similar to visibility engines <NUM> and <NUM> - not shown).

Control logic modules <NUM> that process packets of FL4, FL5 and FL6, pass descriptors of packets belonging to FL4, FL5 and FL6 that have been admitted to queueing system <NUM> for transmission by packet Tx <NUM> via a common egress port <NUM> or via two or three egress ports. Control logic modules <NUM> that process packets of FL4, FL5 and FL6, report packets of FL4, FL5 and FL6 that have been dropped to the SB controller, which releases the dropped packets from SB <NUM>.

<FIG> is a flow chart that schematically illustrates a method for data-plane processing for flow-based admission, in accordance with an embodiment that is described herein.

The method will be described as executed by network element <NUM> of <FIG>. In performing the method of <FIG> it is assumed that SB controller has produced, using previously received packets, admission states <NUM> that are accessible by admission decision modules <NUM>. A method for producing admission states will be described with reference to <FIG> below.

The method of <FIG> begins with network element <NUM> receiving a packet via an ingress port <NUM> and storing the received packet in SB <NUM>, at a packet reception step <NUM>. The ingress port in question is denoted "PI.

At a packet analysis step <NUM>, parser <NUM> parses the packet header(s) to generate a descriptor for the packet. Parser <NUM> passes the descriptor to descriptor processor <NUM>, which based on the descriptor determines the following parameters:.

At an admission states accessing step <NUM>, admission decision module <NUM> reads one or more admission states associated with (PI,Rp), (PO,Tp) and FL. As noted above, admission states associated with (PI,Rp) and with (PO,Tp) are produced by SB controller <NUM> based on occupancy data counts <NUM>, and admission states associated with FL are produced by SB controller <NUM> based on flow-based data counts <NUM>.

At a decision step <NUM>, admission decision module <NUM> decides, based on the one or more admission states observed at step <NUM>, whether to admit or drop the packet.

At an admission query step <NUM>, descriptor processor <NUM> checks whether the packet should be admitted. When the decision at step <NUM> is to drop the packet, the method loops back to step <NUM> to receive another packet. Descriptor processor <NUM> also reports the dropped packet to the SB controller for releasing storage space occupied by the dropped packet. When the decision at step <NUM> is to admit the packet, descriptor processor <NUM> proceed to a queueing step <NUM>. At step <NUM>, the descriptor processor places the corresponding descriptor in an appropriate queue in queueing system <NUM> to await transmission via the designated egress ports PO at the transmission priority Tp. At a consumption reporting step <NUM>, descriptor processor <NUM> reports consumption information related to the admitted packet to SB controller <NUM> for accounting. Following step <NUM>, the method loops back to step <NUM> to receive a subsequent packet.

At a release reporting step <NUM>, upon transmission of the queued packet via the port PO, packet Tx <NUM> reports the release event to SB controller <NUM>, for accounting update and refreshing relevant admission states.

<FIG> is a flow chart that schematically illustrates a method for producing flow-based admission states, in accordance with an embodiment that is described herein.

The method will be described as executed by SB controller <NUM> of <FIG>.

The method of <FIG> begins with SB controller waiting for receiving consumption and release notifications, at a waiting step <NUM>. As noted above, descriptor processor <NUM> generates a consumption notification in response to packet admission, and packet transmitter <NUM> generates a release notification in response to transmitting a previously admitted and queued packet. It is assumed that each consumption/release notification comprises a pointer to a descriptor of the underlying packet, which is indicative of the flow FL to which the packet belong, and to the regions (PI,Rp) and (PO,Tp) of the packet.

In response to receiving a consumption notification corresponding to a given packet, SB controller <NUM> increases a flow-based data count associated with a flow FL to which the given packet belongs. The SB controller also increases occupancy data counts associated with regions (PI, Rp), (PO, Tp) of the given packet. Let DC denote the amount of data corresponding to the given packet. At step <NUM>, the SB controller calculates updated data counts as follows: Count(FL) += DC, Count(PI,Rp) += DC, and Count(PO,Tp) += DC.

In response to receiving a release notification corresponding to a given packet, SB controller <NUM> decreases a flow-based data count associated with a flow FL to which the given packet belongs. The SB controller also decreases occupancy data counts associated with regions (PI, Rp), (PO, Tp) of the given packet. Let DC denote the amount of data corresponding to the given packet. At step <NUM>, the SB controller calculates updated counts as follows: Count(FL) -= DC, Count(PI,Rp) -= DC, and Count(PO,Tp) -= DC.

Following each of steps <NUM> and <NUM>, the method proceeds to an admission states refreshing step <NUM>, at which SB controller <NUM> updates admission states <NUM> associated with FL, (PI,Rp) and (PO,Tp) to reflect the effect of the consumption or release events. Following step <NUM>, the method loops back to step <NUM> to wait for a subsequent notification.

Mirroring is a technique used, for example, by network elements for reporting selected events, e.g., for the purpose of troubleshooting and performance evaluation. In mirroring, packets selected using a predefined criterion (e.g., congestion detection) may be reported to a central entity for analysis. The selected packets are duplicated and transmitted to the network, and therefore may undesirably consume a significant share of the available bandwidth.

In some embodiments, a mirroring criterion comprises a flow-based criterion. For example, packets belonging to a certain flow (FL) may be mirrored based on a flow-based count assigned to FL, e.g., using visibility engine <NUM> or <NUM>. In some embodiments, packets of FL may be mirrored based on flow-based data counts of other flows. Additionally, packets belonging to FL may be mirrored based on one or more occupancy data counts that are associated with FL. In some embodiments, a flow-based mirroring criterion may be combined with another mirroring criterion such as identifying a congestion condition.

Weighted Random Early Detection (WRED) is a method that may be used for congestion avoidance. In WRED, the probability of dropping packets increases as the transmission queue builds up.

In some embodiments, admission decision module <NUM> comprises a flow-based WRED module (not shown) that participates in deciding on packet admission or drop. Specifically, SB controller <NUM> calculates a drop probability based at least on a flow-based data count associated with one or more selected flows, and generates a flow-based admission state for the one or more flows based on the flow-based data count and on the drop probability. In some embodiments, the SB controller determines the admission state also based on one or more occupancy data counts.

The embodiments described above are given by way of example, and other suitable embodiments can also be used. For example, in the embodiments described above, the flow-based accounting is carried out relative to ingress ports. In alternative embodiments, however, the flow-based accounting is carried out relative to egress ports.

Although the embodiments described herein mainly address flow-based management of a SB in a network element, the methods and systems described herein can also be used in other suitable network devices, such as in managing a SB of a Network Interface Controller (NIC).

It will be appreciated that the embodiments described above are cited by way of example, and that the following claims are not limited to what has been particularly shown and described hereinabove. Rather, the scope includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art. Documents incorporated by reference in the present patent application are to be considered an integral part of the application except that to the extent any terms are defined in these incorporated documents in a manner that conflicts with the definitions made explicitly or implicitly in the present specification, only the definitions in the present specification should be considered.

It will be understood that aspects and embodiments are described above purely by way of example, and that modifications of detail can be made within the scope of the claims.

Each apparatus, method, and feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Claim 1:
An apparatus for controlling a Shared Buffer, SB, (<NUM>) the apparatus comprising:
an interface (<NUM>) configured to access flow-based data counts (<NUM>) and admission states (<NUM>);
a SB controller (<NUM>) configured to:
perform flow-based accounting of packets received by a network device (<NUM>) coupled to a communication network (<NUM>) for producing flow-based data counts, each flow-based data count associated with one or more respective flows; and
generate admission states (<NUM>), wherein the admission states comprise flow-based admission states based at least on the flow-based data counts, each flow-based admission state being generated from one or more respective flow-based data counts; and
multiple ports including an ingress port (<NUM>), configured to connect to the communication network; and
data-plane logic, configured to:
receive a packet from the ingress port;
classify the packet into a respective flow; and
based on a plurality of the generated admission states, decide whether to admit the packet into the SB or drop the packet.