Telefonaktiebolaget Lm Ericsson (publ)

László Molnár

Gergely Pongrácz

Gabor Sandor Enyedi

Panagiotis Saltsidis

János Farkas

Balázs Peter Gerö

Zoltan Lajos Kis

Balázs Varga

Zoltán Lajos Kis

A method is implemented by a network device to dynamically optimize lookup speed in a packet processing table maintained at the network device while the network device is in operation. The method includes determining one or more runtime metrics of the packet processing table, selecting a lookup algorithm for the packet processing table from a set of lookup algorithms supported by the network device based on the one or more runtime metrics of the packet processing table, and configuring the network device to match incoming packets against rules in the packet processing table using the selected lookup algorithm for the packet processing table.

Dynamic lookup optimization for packet classification

A technique for status change handling in an interconnect node is described, wherein the node comprises a data plane that can assume, per service, a passive or active status. A method aspect in the node comprises transmitting, to another node, a first indication that a change has been or is about to be performed, awaiting, from the other node, reception of a second indication that the data plane in the other node has been set to the passive status, and activating, responsive to the received indication, the data plane of the node from the passive status to the active status. The method aspect in the other node further comprises receiving, from the node, the first indication, passivating, responsive to the receiving step, the data plane being in the active status to the passive status, and transmitting, upon completion of the passivating step, the second indication.

Technique for handling a status change in an interconnect node

The invention relates to a counting unit () configured to count an amount of traffic events of a data packet traffic. The counting unit comprises a counting element () configured to store a value representing the amount of traffic events. The counting unit further comprises a processing unit (-) configured to detect an arrival of each data packet of the data packet traffic at the processing unit, to process each data packet and to determine whether the value at counting element () should be increased each time the arrival of one data packet is detected at the processing unit, wherein the processing unit (-) is configured to store a probability value p&#x3c;1 indicating a probability that the processing unit increases the value at the counting element each time the arrival of one data packet is detected at the processing unit, wherein the processing unit is configured such that when it detects the arrival of one data packet at the processing unit, it increases the value at the counting element only with the probability p.

Counter with reduced memory access

The present disclosure provides a technique for ensuring that a service or conversation is carried in a congruent manner on a Link Aggregation Group (LAG). The Service ID (e.g., conversation ID) to link mapping is configured on both sides of the LAG independently of each other. The Service ID to link assignment is stored in a well-defined format, e.g. in an assignment table. A digest is then prepared on the assignment table. The digest is exchanged between the two sides of the LAG. If there is a mismatch between the digests, then the service is transmitted on a predefined and agreed-upon default link if congruency has to be enforced for that particular service. Furthermore, the digest exchange allows verification on the configuration to check whether all services to be handed-off are configured on both sides.

Technique for ensuring congruency in link aggregation

A packet switching device can process packets by linking pre-compiled code fragments corresponding to actions to be performed for a packet flow, in order to generate a flow function. Once generated, the packet switching device can invoke this flow function for one or more packets in the packet flow. For example, a linker could use a flow table to determine the actions to be performed for a packet flow. Those actions may correspond to code fragments which have already been compiled and make use of symbols as placeholders for parameters yet to be defined. To generate a flow function, the pre-compiled code fragments corresponding to the actions of a flow can be sequenced and linked together. The parameter values of the actions can then replace the placeholder symbols. Once fully assembled, the flow function can be written to memory and executed any time a packet for the corresponding flow needs to be routed.

Growing community of inventors

Budapest, Hungary

László Molnár