Adaptive traffic arbitration engine

Abstract

The invention relates to frame arbitration in a network entity, e.g. for data forwarding, switching, routing or gateways. A hardware device for the frame arbitration, a frame having a frame format suitable for the frame arbitration and a method for the frame arbitration are proposed. The hardware device comprises N>1 ingress ports for receiving N frames, M>1 egress ports for outputting M frames, and a processing circuitry connected to the ingress ports and the egress ports. Each frame comprises a frame header comprising a frame priority field, the frame priority field comprising a set of bits comprising two or more subsets of bits, each subset of bits indicating arbitration metadata. The processing circuitry is configured to determine, when a first frame and a second frame are received simultaneously, based on the frame priority fields, which one of the first frame and the second frame to process and output at the egress ports in a next clock cycle.

Description

TECHNICAL FIELD

[0001] The present invention relates to network traffic arbitration in a network entity, wherein network traffic is processed in frames. The network entity can be used for data forwarding, switching, routing or gateways in a communication network. The invention proposes a hardware device for frame arbitration in a network entity. Furthermore, the invention proposes a frame with a frame format suitable for frame arbitration and a method for performing frame arbitration. BACKGROUND

[0002] Conventional switching or gateway solutions that can be found in network entities, like gateways used in the automotive industry, are typically based on a software-centric implementation. In such a software-centric solution, a frame arbitration policy for forwarding frames from a plurality of ingress ports to a plurality of egress ports of the network entity is determined by a routing algorithm that can be executed by a core processing unit, e.g. a CPU of a microcontroller unit (MCU) or a system on chip (SoC) device.

[0003] The arbitration policy can become complex in terms of timing requirements, especially in network entities with a considerable number of high-speed ingress and egress ports that have to handle a large amount of network traffic, wherein at least a part of the network traffic is critical in terms of functional safety and / or time determinism requirements. This is the case, for example, for future 100 Mbps, 1000 Mbps or even multi-gigabit automotive Ethernet.

[0004] The software-centric solution can lead to data throughput bottlenecks and design challenges that are difficult to overcome. Furthermore, the software-centric solution can not scale well due to its complexity. SUMMARY

[0005] In view of the above, the present invention aims at providing an improved solution for arbitrating frames in a network entity. The objectives to be achieved include that the frame arbitration solution involves a reduced complexity in terms of programming (is scalable) and provides similar or better performance than conventional solutions, e.g. the software-centric solution described above.

[0006] These and other objectives are achieved by the solutions described in the independent claims. Advantageous implementations are further described in the dependent claims.

[0007] The first aspect of the present invention provides a hardware device for frame arbitration in a network entity, the hardware device comprising: N ingress ports for receiving N frames, wherein N > 1; M egress ports for outputting M frames, wherein M > 1; processing circuitry connected to the ingress ports and the egress ports; wherein each frame comprises a frame header comprising a frame priority field, wherein the frame priority field comprises a set of bits, and wherein the set of bits comprises two or more subsets of bits, each subset of bits indicating a respective arbitration metadata; and wherein the processing circuitry is configured to, when at least a first frame and a second frame are simultaneously received at the ingress ports: determine, based on the set of bits in the frame priority field of the first frame and the second frame, respectively, which one of the first frame and the second frame is to be processed and output at the egress ports sequentially or concurrently in a next clock cycle.

[0008] According to the first aspect, the present invention proposes a hardware-centric approach for frame arbitration in a network entity, instead of a software-centric approach. The hardware-centric approach can reduce the level of complexity in terms of programming. The approach of the present invention also has a better scalability and can achieve a better level of performance (e.g., in terms of key performance indicators (KPIs) including latency and jitter of frames or in terms of data throughput through the network entity) than a conventional software-centric approach. The hardware-centric approach of the present invention can automate all routing and forwarding procedures that are assigned to the network entity at different processing stages.

[0009] For example, the network entity can be a car gateway in a vehicle and the hardware device can be comprised in a gateway controller. However, the network entity can also be a switch or a router, etc.

[0010] The hardware device of the first aspect can provide a fully autonomous frame arbitration approach that exclusively operates in hardware without any software intervention at all. It is noted that software in the present invention is understood as machine instructions described by source code that are executed by a processor like a CPU. In the present invention, the hardware device is responsible for the arbitration of frames from the ingress ports to the egress ports without the need for such machine instructions.

[0011] Each frame can require different types of processing tasks, and the hardware device can be capable of performing these different types of processing tasks on frames in parallel. Frame arbitration can comprise assigning the frames received at the ingress port to those processing tasks required. The processing tasks can be performed by one or more processing resources of the hardware device, for example by one or more hardware accelerators. Any frame can also be associated with two or more processing tasks which have to be completed sequentially, for example according to a specific processing order. In this case, this frame can be processed by performing the processing tasks one after the other in the processing order.

[0012] For example, if the first frame and the second frame require the same one or more processing tasks, and for example these processing tasks have to be performed by the same one or more processing resources, the frame arbitration can be performed by the hardware device. In this case, according to a determination of the processing circuitry of the hardware device, one of the first frame and the second frame can occur before the other frame, and the other frame can for example wait in a queue until the processing resource is free again after processing the first frame. In this way, the frame arbitration can take effect, and the processing circuitry can decide which of the two frames competing for the same one or more processing resources has a higher priority.

[0013] In an implementation form of the first aspect, the processing circuitry is configured to update the set of bits in the frame priority field of each frame before the frame is processed and output at the egress port.

[0014] Thus, for example, another hardware device also designated for processing the one or more frames (output by the hardware device of the first aspect) as described in the first aspect can use the one or more updated frame priority fields for further frame arbitration. For example, each processing stage of a plurality of processing stages of the network device can comprise a hardware device according to the first aspect, and each hardware device can perform frame arbitration for its associated processing stage according to the frame priority fields in the frames it receives at its ingress port.

[0015] In an implementation form of the first aspect, the set of bits in the frame priority field of the frame is updated based on information contained within the frame and / or based on available information of the network environment and the hardware device itself.

[0016] The available information can comprise at least one of a state of the network and a state of the hardware device.

[0017] In an implementation form of the first aspect, the set of bits in the frame priority field of the frame is updated based on at least one of: a status of a queue in which the frame is received; a time-out and / or a timestamp of the frame; a list of one or more network processing tasks to be performed on the frame; a status of one or more hardware accelerators on which one or more network processing tasks have to be performed before the frame is output; a status of a time sensitive network shaper of the frame to be output; an in-band telemetry status; a virtual local area network tag priority of the frame.

[0018] In an implementation form of the first aspect, each frame comprises an instruction frame and a data frame, wherein the frame header comprising the frame priority field belongs to an instruction frame.

[0019] In an implementation form of the first aspect, the hardware device is configured to receive and output each instruction frame in a control plane; and to receive and output each data frame on a data plane.

[0020] In an implementation form of the first aspect, the processing circuitry is configured to separate each frame received at the ingress port into an instruction frame and a data frame, wherein the instruction frame is provided with the frame header comprising the frame priority field.

[0021] According to the above implementation forms describing the instruction frame and the data frame, respectively, the solution of the application supports a software defined networking (SDN) approach, which implies the separation into the data plane and the control plane.

[0022] In an implementation form of the first aspect, the processing circuitry is further configured to process the data frame of each frame according to instructions comprised in the frame header and a payload of the instruction frame of the frame before outputting the frame at the egress port.

[0023] The instructions comprised in the instruction frame can be processed by the hardware device in order to control the processing of the data frames. For example, the processing circuitry of the hardware device can automatically process the data frames according to instruction bits of the instructions comprised in the instruction frame without any software interaction. Thus, the processing circuitry can also arbitrate the processing of different data frames according to the set of bits in the respective frame priority information field of the instruction frame associated with these different data frames.

[0024] In implementations of the first aspect, the processing circuitry is configured to associate a weight with the subset of bits in the frame priority field of each frame; and to determine which of the first frame and the second frame to output at the egress port in the next clock cycle further based on the weights respectively associated with the subset of bits in the frame priority field of the first frame and the second frame and by executing a sorting algorithm.

[0025] In this way, the priority of the frames can be performed and / or changed by the hardware device.

[0026] In implementations of the first aspect, the processing circuitry comprises a set of configurable multiplexers, wherein different configurations of the set of configurable multiplexers correspond to different weights associated with the subset of bits in the frame priority field of each frame.

[0027] For example, the multiplexers can automatically determine which of the first frame and the second frame to first process and output at the egress port in the next clock cycle according to the weighted subset of bits in the frame priority field of the first frame and the second frame.

[0028] In implementations of the first aspect, the N ingress ports are connected to N or more parallel queues for providing the N ingress frames in parallel from the N ingress ports; and / or the M egress ports are connected to M or more parallel queues for receiving the M egress frames in parallel and sending them in parallel to the M egress ports.

[0029] Frames that have to wait for processing due to the frame arbitration can be kept in the queues. For example, the hardware device can receive parallel frames at ingress ports, can provide them to the parallel queues, and can select them one by one from the parallel queues for processing according to the frame priority field. For example, the hardware device can provide the processed frames into parallel queues, and can further output these frames from the queues at the egress ports.

[0030] A second aspect of the present application provides an instruction frame having a frame format suitable for frame arbitration in a network entity, the frame format comprising: a frame header; wherein the frame header comprises a frame priority field; wherein the frame priority field comprises a set of bits; wherein the frame priority field comprises a set of bits, wherein the set of bits comprises two or more subsets of bits, and wherein each subset of bits indicates respective arbitration metadata.

[0031] The instruction frame of the second aspect, in particular the frame priority field, enables the hardware-centric approach of the application for the frame arbitration, as implemented by the hardware device of the first aspect. Thus, the frame format of the instruction frame yields the advantages described above for the hardware device.

[0032] In implementation forms of the second aspect, the respective arbitration metadata comprises one or more bits indicating a priority of the instruction frame.

[0033] Thus, in case the same processing resource has to be used for two or more frames, the two or more frames are processed one after the other by the processing circuitry of the hardware device of the first aspect depending on the priority of the two or more frames, for example.

[0034] In implementation forms of the second aspect, the respective arbitration metadata further comprises at least one of: one or more bits indicating a queue status of a queue providing the frame; one or more bits indicating a timeout or timestamp of the frame; one or more bits indicating a list of one or more processing tasks to be performed on the frame; one or more bits indicating a status of one or more hardware accelerators, wherein one or more network processing tasks have to be performed on the frame; one or more bits indicating a time sensitive network shaper of the frame; one or more bits indicating an in-band telemetry status; one or more bits indicating a virtual local area network tag priority of the frame.

[0035] In implementation forms of the second aspect, the frame priority field is a first field in the frame header.

[0036] This facilitates a fast response, thereby facilitating a processing efficiency of the hardware device of the first aspect processing the frame, for example.

[0037] In implementation forms of the second aspect, the frame format of the frame is based on one of the following protocols: controller area network (CAN); CAN flexible data rate, CAN XL, local interconnect network, FlexRay, media oriented systems transport, Ethernet, mobile industry processor interface, or camera serial interface 2.

[0038] Thus, the instruction frame of the second aspect is compatible with a plurality of established network protocols.

[0039] In implementation forms of the second aspect, the frame format of the frame is a standardized frame format comprising a plurality of fields, wherein each field is parameterized by a field index or offset parameter and a field size parameter.

[0040] This enables a network entity (e.g. a car gateway) to efficiently handle various network protocols used together.

[0041] In an implementation form of the second aspect, the instruction frame further comprises a frame header and a payload, wherein the frame header and the payload comprise instructions indicating how a data frame associated with the instruction frame is to be processed by a processing circuitry of a hardware device.

[0042] A third aspect of the present application provides a method for frame arbitration in a network entity, the method being performed by a hardware device and comprising: receiving at least a first frame and a second frame simultaneously at a plurality of ingress ports of the hardware device; wherein each frame comprises a frame header comprising a frame priority field, wherein the frame priority field comprises a set of bits, and wherein the set of bits comprises two or more subsets of bits, each subset of bits indicating a respective arbitration metadata; and determining, by a processing circuitry of the hardware device, which one of the first frame and the second frame is to be processed and output sequentially or concurrently at a plurality of egress ports of the hardware device in a next clock cycle based on the set of bits in the frame priority field of the first frame and the second frame, respectively.

[0043] In an implementation form of the third aspect, the processing circuitry updates the set of bits in the frame priority field of each frame before the frame is processed and output at the egress port.

[0044] In an implementation form of the third aspect, the set of bits in the frame priority field of the frame is updated based on information contained within the frame and / or based on available information of the network environment and the hardware device itself.

[0045] In an implementation form of the third aspect, the set of bits in the frame priority field of the frame is updated based on at least one of: a state of a queue in which the frame is received; a timeout and / or a timestamp of the frame; a list of one or more network processing tasks to be performed on the frame; a state of one or more hardware accelerators, wherein one or more network processing tasks have to be performed on the frame before the frame is output; a state of a time sensitive network shaper of the frame to be output; an in-band telemetry state; a virtual local area network tag priority of the frame.

[0046] In an implementation form of the third aspect, each frame comprises an instruction frame and a data frame, wherein the frame header comprising the frame priority field belongs to an instruction frame.

[0047] In an implementation form of the third aspect, the hardware device receives and outputs each instruction frame in a control plane; and receives and outputs each data frame on a data plane.

[0048] In implementations of the third aspect, the processing circuitry separates each frame received at the ingress port into an instruction frame and a data frame, wherein the instruction frame is provided with the frame header including the frame priority field.

[0049] In implementations of the third aspect, the processing circuitry processes the data frame of each frame according to the instructions included in the frame header of the frame and the payload of the instruction frame before outputting the frame at the egress port.

[0050] In implementations of the third aspect, the processing circuitry associates a weight with the subset of bits in the frame priority field of each frame; and determines which one of the first frame and the second frame to output at the egress port in the next clock cycle further based on the weights respectively associated with the subset of bits in the frame priority field of the first frame and the second frame and by executing a sorting algorithm.

[0051] In implementations of the third aspect, N or more parallel queues provide the N ingress frames in parallel from the N ingress ports; and / or M or more parallel queues receive the M egress frames in parallel and send them in parallel to the M egress ports.

[0052] The method of the third aspect provides the same advantages as described above for the hardware device of the first aspect.

[0053] The hardware-centric solution of the present application can be applied to any type of network entity, e.g. a switch, a smart network interface card (NIC), a router, a gateway. The hardware device implements arbitration of frames inside the network entity in order to implement network traffic arbitration in an autonomous and automated manner. The frame arbitration of the hardware device does not require software interaction (however, software can be used to define a start-up configuration). The hardware device does not need to be processed by a CPU executing source code lines, a fact that improves performance and time determinism and other quality of service (QoS) metrics.

[0054] The hardware device can be synthesized in silicon, can comply with SDN network architecture at device level, and can be distributed on the control plane and data plane of the network entity. The processing circuitry of the hardware device can perform the network traffic arbitration in a distributed manner at different processing levels of the network entity, e.g. processing levels for frame priority policing, queuing or dequeuing, processing and / or shaping. Therefore, no delay, jitter and overhead in terms of resource consumption are practically incurred thanks to the optimized hardware architecture of the hardware device.

[0055] The hardware device can also adapt its behavior, e.g. according to a predefined rule-based arbitration algorithm (e.g. round robin) or on-the-fly in response to changing network environment conditions (e.g. network congestion, internal queue overflow status or per-frame timeout expiration). This can be done at runtime without interrupting operation of the network entity.

[0056] The hardware device can be controlled by the bitset in the frame priority field of the frame, wherein the arbitration metadata (bit subset) in the bitset can be based on a large and diverse input set, some of the inputs being static and can be (re)configurable through a set of registers (e.g. memory mapped) of the hardware device, and other inputs being dynamically updated by the hardware device itself on-the-fly based on real-time conditions of the network and the device itself (e.g. traffic status, memory status, arbitration priority status, etc.). The priority given to the bits of the bitset can lead to a diverse and flexible set of operating modes of the hardware device.

[0057] It is noted that the hardware device is also referred to as "distributed arbitration engine (DAE)" in the present application.

[0058] It is noted that all devices, elements, units and means described in the present application can be implemented as hardware elements. All steps of the methods performed by the various entities described in the present application and the functions described to be performed by the various entities are intended to be carried out by the respective entity. Even if a specific function or step is not reflected in the description of a specific detailed element of the entity performing that specific step or function, it is to be understood for the skilled in the art that these methods and functions can be implemented in respective hardware elements. BRIEF DESCRIPTION OF DRAWINGS

[0059] The above described various aspects and their implementation can be illustrated by the following, non-limiting description of specific embodiments in conjunction with the attached drawings, in which:

[0060] Figure 1 A hardware device for frame arbitration in a network entity according to the present application is shown.

[0061] Figure 2 An instruction frame with a frame format suitable for frame arbitration according to the present application is shown.

[0062] Figure 3 An exemplary architecture of a network entity, in particular a car gateway controller, in which a hardware device according to the present application is deployed is shown.

[0063] Figure 4The decoupling of the control plane from the data plane according to the SDN approach is shown, which can be implemented by the hardware device of the present invention.

[0064] Figure 5 The decoupling of the control plane from the data plane across exemplary network entities in which the hardware device of the present invention is deployed is shown.

[0065] Figure 6 An example of frame arbitration performed by the hardware device of the present invention based on the frame priority field is shown.

[0066] Figure 7 An exemplary architecture of the hardware device of the present invention is shown, which can be used for a car gateway controller.

[0067] Figure 8 The adjustment of the frame priority field by using a multiplexer is shown.

[0068] Figure 9 A method for frame arbitration in a network entity according to the present invention is shown. DETAILED DESCRIPTION

[0069] Figure 1 A hardware device 100 according to the present invention is shown. The hardware device 100 is used for performing frame arbitration in a network entity. To this end, the hardware device 100 can be deployed in the network entity. For example, the hardware device can comprise a processing circuitry 105, and this processing circuitry 105 can be installed in the network entity. For example, the processing circuitry 105 can be deployed in a distributed manner in the network entity. For example, the processing circuitry 105 can be comprised in one or more processing stages of the network entity. Each processing stage of the network entity can be used for performing one or more processing tasks on one or more frames.

[0070] The processing circuitry 105 can be responsible for performing, conducting or initiating the various operations of the hardware device 100 described in the present invention. The processing circuitry 105 can comprise analog circuitry, digital circuitry or both analog and digital circuitry. The digital circuitry can comprise components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs) or multi-purpose processors, etc. The hardware device 100 can further comprise memory circuitry for storing information. For example, the hardware device 100 can comprise one or more queues, such as one or more first-in first-out (FIFO) memories for storing and queuing frames, e.g. between processing stages.

[0071] In addition to the processing circuit 105, the hardware device 100 further includes N input ports 101 for receiving N frames 102 and M output ports 103 for outputting M frames 102. Thus, both N and M are integers, N>1 and M>1. In Figure 1 , for example, N = 4 and M = 3. Usually it is possible that N>M, but it is also possible that N<M or N = M. As Figure 1 shown, the processing circuit 105 is connected to the input ports 101 and the output ports 103 of the hardware device 100.

[0072] Each frame 102 processed by the hardware device 100 can be designed as shown in the upper part of Figure 2 . Specifically, each frame 102 includes a frame header 201 containing a frame priority field 202, where the frame priority field 202 includes a bit set. This bit set includes two or more bit subsets, where each bit subset indicates corresponding arbitration metadata. Each frame 102 may optionally further include a payload 205 and / or a tail 206.

[0073] As Figure 2 further shown, the frame 102 can be an instruction frame 203. Or, it can include an instruction frame 203. In the first case, if the frame 102 is an instruction frame 203, then the optional lower part of Figure 2 is redundant. In the second case, if the frame 102 includes an instruction frame 203, then as shown in the lower part of Figure 2 by the dashed box, the frame 102 can include an instruction frame 203 and, in addition, a data frame 204. That is, the frame 102 can be separated into an instruction frame 203 and a data frame 204. In this case, the frame header 201 including the frame priority field 202 belongs to the instruction frame 203, as shown in the figure.

[0074] If the frame 102 includes an instruction frame 203 and a data frame 204, then in addition to the frame priority field 202 of the frame header 201, the frame header 201 and / or the optional payload 205 of the instruction frame 203 may further include an instruction. This instruction indicates how, for example, the processing circuit 105 of the hardware device 100 or one or more processing levels of a network entity will process the data frame 204 that belongs to the same frame 102 as the instruction frame 203 in this case.

[0075] In any case, the processing circuit 105 is used for when at least a first frame 102a and a second frame 102b are simultaneously received at the input port 101 (where both are frames 102, for example as shown in Figure 2When the first frame 102a and the second frame 102b are received at the ingress port 101 (simultaneously or consecutively), it is determined which one of the first frame 102a and the second frame 102b is processed and output at the egress port 103 (sequentially or concurrently) in the next clock cycle. That is, the processing and output order between the first frame 102a and the second frame 102b is determined. This determination is performed by the processing circuit 105 based on the bit set in the frame priority field 202 of the first frame 102a and the second frame 102b, respectively. The processing circuit 105 can process the bit set in the frame priority field 202 of the first frame 102a or the bit set in the frame priority field 202 of the second frame 102b. Based thereon, it can determine the higher priority frame of the two frames 102a, 102b and can first process and output this higher priority frame at the egress port 103.

[0076] Each bit set can be regarded as a control word that is used to determine the priority of the frame 102 to which it belongs. The processing and output order between the first frame 102a and the second frame 102b can automatically occur in the processing circuit 105 according to this control word. Different types of arbitration metadata can be encoded by subsets of bits in the frame priority field 202. The determination step of the processing circuit 105 does not require software or a processor operating based on software or machine instructions. By performing the determination step, at least frame arbitration between the first frame 102a and the second frame 102b is achieved. Of course, the determination step can be done based on any two frames 102 received at the ingress port 101 simultaneously, e.g. from two or more parallel queues connected to the ingress port 101, and likewise can be performed for more than two frames 102 received in parallel. Thus, the hardware device 100 is suitable for frame arbitration, in general network traffic arbitration.

[0077] Figure 3 An example of a network entity 300 is shown, in which the hardware device 100 can be implemented. In this example, the network entity 300 is a car gateway that comprises the hardware device 100. In particular, the hardware device 100 can be implemented in a gateway controller of the gateway. It is noted that the network entity 300 can also belong to a different type, e.g. the network entity 300 can be a smart network interface card (NIC), a switch or a router.

[0078] As also Figure 3 indicated, the network entity 300 can comprise multiple processing stages. For example, in the exemplary case, the network entity 300 can comprise four processing stages. These processing stages are indicated by the four processing stages 301, 302, 303, 304 in the example of Fig. 3. Figure 3The four stages are respectively referred to as "frame normalizer", "filtering and policing", "gateway (signaling and PDU)", and "traffic shaping". Each processing stage of the network entity 300 can be used to perform one or more different processing tasks on each frame 102. The frames 102 can follow a data path through the network entity 300 that directs the frames 102 through each of the multiple processing stages.

[0079] The hardware device 100 is represented in Figure 3 The processing circuitry 105 of the hardware device 100 can be located in each processing stage of the network entity 300. The processing circuitry 105 of the hardware device 100 can be distributed across these processing stages.

[0080] In one example, as Figure 3 each processing stage can comprise at least one DAE. Thus, the one or more DAEs of each respective processing stage can be considered to form the hardware device 100 as described above in relation to Figure 1 In this case, the ingress port of the respective processing stage can correspond to the ingress port 101 of the hardware device 100, and in this case, the egress port of the respective processing stage can correspond to the egress port 103 of the hardware device 100. Notwithstanding this, the one or more DAEs deployed in each of the multiple processing stages of the network entity 300 can also be considered to form a distributed hardware device 100. In this case, the ingress port of the network entity 300 can correspond to the ingress port 101 of the hardware device 100, and the egress port of the network entity 300 can correspond to the egress port 103 of the hardware device 100. This distributed implementation of the processing circuitry 105 across the processing stages of the network entity 300 can have only negligible overhead in terms of hardware resources, and in fact no penalty in terms of latency or jitter of the frames.

[0081] The interface between one processing stage and the next processing stage in the network entity 300 can be based on one or more queues of the network entity 300 (e.g., FIFO memory). Distributed arbitration by the processing circuitry 105 of the one or more hardware devices can be applied across all frames 102 that move through all the processing stages of the network entity 300. Frame arbitration can be necessary when two frames 102 arrive at a processing stage at the same time and need to be processed with the same processing resource. Prior to that processing stage, the frames 102 can be temporarily stored in the queues, and the processing circuitry 105 can determine which of the frames 102 stored in those queues are first processed in the processing stage with the required processing resource.

[0082] In general, all frames 102 provided in parallel and / or subsequently to the ingress ports of the network entity 300 can flow through all processing stages of the network entity 300, can be processed by each processing stage, and can then be output in parallel and / or subsequently at the egress ports of the network entity 300. The processing circuitry 105 of the hardware device 100 can decide which frames 102 need to be processed by which processing resources of the processing stages at which times, wherein all these decisions can be based on priority criteria encoded into the respective frame priority fields 202 of the frames 102. Optionally, these frame priority fields 202 can be updated in one or more or each processing stage of the network entity 300, respectively, after processing the frames 102. In this way, the encoded priority criteria can be changed or reconfigured.

[0083] As Figure 4 illustrated, inspired by the SDN approach, the processing circuitry 105 of the hardware device 100 can be configured to separate each frame 102 it receives at its ingress ports 101 into an instruction frame 203 and a data frame 204, as Figure 2 illustrated. For example, in Figure 3 , each frame 102 input to the first processing stage (“frame normalizer”) of the network entity 300 can be split into an instruction frame 203 and a data frame 204 by the processing circuitry 105 deployed in this processing stage in this way. The instruction frame 203 can contain the arbitration metadata in the frame priority field 202 and can contain additional metadata, e.g., metadata of the original frame 102. The data frame 204 can contain essentially the payload of the original frame 102.

[0084] The processing circuitry 105 of the hardware device 100 can also be configured to have received and output the instruction frames 203 in the control plane and to have received and output the data frames 204 in the data plane. In this case, the processing circuitry 105 can not necessarily perform the separation. That is, the processing circuitry 105 can receive, process, and output the frames 102 in already separated fashion, as Figure 2 illustrated. For example, in Figure 3 , after the frames 102 have been separated in a processing stage, the processing circuitry 105 in one or more subsequent processing stages can process the instruction frames 203 including the frame priority fields 202 and the data frames 204 in the control plane and the data plane, respectively.

[0085] In other words, each frame 102 can first be regenerated in the network entity 300 as an instruction frame 203 and a data frame 204, and from this step, the instruction frame 203 can be equipped with a frame priority field 202 describing the priority assigned to this frame 102, in particular the data frame 204. The frame priority field 202 can be used to perform arbitration with other frames 102 in each processing stage of the network entity 300. For example, the processing circuitry 105 in each processing stage can determine which frame 102 of two or more frames stored in a queue before the processing stage can first be selected for processing in the processing stage. This frame arbitration is performed according to priority levels of the frames 102 queued in parallel, which are determined by the set of bits in their respective frame priority field 202. These priority levels are determined by the arbitration metadata encoded into the frame header 201.

[0086] Thus, the priority level of each frame 102 is encoded in the frame priority field 202. This field 202 can be the first field of the frame header 201, which is advantageous for efficiency (implementation and execution). In this case, the frame priority field 202 can be the first segment read by the processing circuitry 105, so that the frame is read without forcing the frame out of the queue, and an immediate response can be given (in only one clock cycle).

[0087] The priority level of any frame 200 can be a function of many variables of the arbitration metadata, for example, including port / queue state (almost empty / almost full), network congestion state, time, frame intrinsic priority, TSN shaper rules, estimated processing time per task, type and number of available hardware accelerators available for use (for example, indicated by the state of shared resource hardware accelerators), estimated telemetry data per flow, etc. All these variables can be directly processed in hardware by the processing circuitry 105 without the need for software.

[0088] By the method of the present invention, as Figure 5 illustrated, a fully SDN layered network entity 300 can be obtained, which can be driven by the arbitration metadata in the frame header 201 of the frames 102, in particular the arbitration metadata in the frame priority field 202. As Figure 5It can be seen that the format of the frame 102 can be based on various different network protocols. For example, the protocol can be CAN, CAN Flexible Data Rate, CAN XL, Local Interconnect Network, FlexRay, Media Oriented Systems Transport, Ethernet, Mobile Industry Processor Interface, or Camera Serial Interface 2. For example, the frame arbitration of the present application performed in the network entity 300 can be inspired by the carrier-sense multiple access with collision detection (CSMA-CD MAC) of the CAN network.

[0089] The arbitration metadata of the frame 102 can be transferred from one processing stage to the next processing stage in the network entity 300. Each processing stage can process the data frame 204 according to the instructions in the instruction frame 203 and can process the instruction frame 203 to move and / or update the frame priority field 202 and optionally other metadata. This can be done by the processing circuitry 105 of one or more hardware devices 100 deployed in a distributed manner in the processing stages, for example. The processing and optionally the modification or update of the arbitration metadata in the frame priority field 202 of each processed frame 102 can be done at runtime.

[0090] In order to provide the best possible arbitration strategy inside the network entity 300, each frame 102 can be provided with different arbitration metadata, which can be organized in one or more information fields of the frame priority field 202. In terms of arbitration strategy, the following factors can participate in the inline priority assignment by the frame priority field 202 of the frame 102. In the following examples, the frame priority field 202 can be a 16-bit control word:

[0091] ■ Highest priority [1 bit: interrupt]

[0092] ■ Queue status [1 bit: (almost) full, (almost) empty]

[0093] ■ Timeout or timestamp [4 bits: time factor]

[0094] ■ Task or hardware accelerator status being processed [2 bits: unused, unused to in use, in use to unused, in use]

[0095] ■ Shaper status [2 bits: unused, unused to in use, in use to unused, in use]

[0096] ■ VLAN tag priority [3 bits: class]

[0097] ■ In-band telemetry status [3 bits: counter]

[0098] As Figure 6As shown, for example, from two or more parallel queues ( Figure 6 In a FIFO (FIFO) process, the selection of two or more queued frames 102 (which can be arranged between successive processing stages of network entity 300) can be completed in just one clock cycle based on the set and subset of bits (arbitration metadata) allocated within the frame priority field 202 of frame 102 (here, instruction frame 203). Frame selection can include an ultrafast sorting process. Due to the encoding of the arbitration metadata embedded in each instruction frame 203, the selection and the order of selection results can be executed in just one clock cycle. This arbitration strategy can outperform other software-based implementations in terms of efficiency.

[0099] like Figure 6 As can be seen, the selection of the next frame 102 to be processed is made by the hardware device 100 based on the instruction frame 203, and each instruction frame 203 can be used to determine how to process the corresponding data frame 204. Both the instruction frame 203 and the data frame 204 can be stored in a parallel FIFO. The processing circuitry 105 of the hardware device 100 can control at least one multiplexer to process the data frames 204 in the order determined based on the instruction frame 203.

[0100] Figure 7 An exemplary architecture of the processing circuitry 105 of the hardware device 100 is shown. Figure 7 by Figure 6 Based on this, it is shown that the processing circuit 105 can arbitrate frame 102 according to the frame priority field 202 in the instruction frame 203 of frame 102, such that the corresponding data frame 204 of frame 102 is processed by multiple processing tasks according to the frame arbitration. Each processing task can be implemented by a hardware accelerator, and multiple multiplexers can be used to arbitrate the data frame 204 into the correct processing task defined by the instruction frame 203 and according to the frame arbitration order determined based on the instruction frame 203. A FIFO can be used to arrange data frames 204 that require the same processing task (specifically, the same hardware accelerator) before and after the multiplexer. The FIFO can also be used to store the corresponding instruction frame 203.

[0101] The frame priority field 202 of any frame 102 can be adaptively reconfigured at runtime (e.g., on the fly). This can be achieved using one or more hardware multiplexers 800, such as... Figure 8 As shown. For example, hardware device 100 may include a set of configurable multiplexers 800. Hardware device 100 can also be used to associate weights with a subset of bits in the frame priority field 202 of any frame 102. In this case, different configurations of the set of configurable multiplexers 800 may correspond to different weights associated with a subset of bits in the frame priority field 202 of each frame 102. Figure 8As can be seen, the multiplexing can reorder the weights associated with the subset of bits in the frame priority field 202. The frame priority field 202 entering the multiplexer 800 can be different from the frame priority field 202 coming out of the multiplexer 800. Thus, the frame priority field 202 is adjusted or reconfigured. The self-reconfiguration (by the hardware device 100) and the (re)configuration can be done on the fly without interrupting the operation of the network entity 300, e.g., by the host CPU. This powerful feature enables different modes of operation. The relative priority given to each frame 102 can accordingly be configurable and can be reconfigured at runtime. For example, the composition of each bit of the frame priority field 202 of each frame 102 can be organized or reorganized such that higher weights are prioritized (little-endian mode): e.g., MSB to LSB.

[0102] The frame arbitration performed based on the processing of the frame priority field 202 by the processing circuitry 105 can be based on the ordering of the set of bits (e.g., according to the resulting values based on the weights assigned to each bit). A simple algorithm can be implemented (to reduce complexity) and an efficient and cost-effective arbitration scheme can be implemented in hardware. Each frame 102 can be properly identified and prepared for arbitration by the hardware device 100, with self-contained arbitration metadata stored in the instruction frame 203. For example:

[0103] Instruction set = PrioFrame (16 bits) + FrameID (PortNo + Timestamp) + Tasks2Exec + ExecNow + SeqNumber +...

[0104] The frame arbitration can also take into account the state of one or more hardware accelerators and one or more internal queues of the network entity 300, e.g., to improve QoS (e.g., to avoid unnecessary message drops in queues) and / or to optimize the usage of shared hardware resources (e.g., management, scheduling, and reuse (loopback) of processing tasks in the switching, routing, or gateway functionality of the network entity 300).

[0105] Furthermore, the frame arbitration of the present invention can be applied to any type of network. That is, it is protocol-agnostic (due to the decoupling by the instruction frame 203). The protocol-agnostic arbitration strategy can be a driver for improved scalability.

[0106] As a conclusion, by putting all the above strategies and implementations together, autonomous and stateful frame arbitration can be dynamically implemented by the network entity 300 based on the environment.

[0107] Figure 9A method 900 according to the present application that can be used for frame arbitration in the network entity 300 is shown. The method 900 is performed by the hardware device 100. The method 900 comprises a step 901 of simultaneously receiving at least a first frame 102a and a second frame 102b at the plurality of ingress ports 101 of the hardware device 100. Each frame 102, 200 comprises a frame header 201 comprising a frame priority field 202, wherein the frame priority field 202 comprises a set of bits, wherein the set of bits comprises two or more subsets of bits, and wherein each subset of bits indicates respective arbitration metadata.

[0108] The method 900 further comprises a step 902 of determining, by the processing circuitry 105 of the hardware device 100, which one of the first frame 102a and the second frame 102b is to be processed and output at the plurality of egress ports 103 of the hardware device 100 sequentially or concurrently in the next clock cycle, based on the set of bits in the frame priority field 202 of the first frame 102a and the second frame 102b, respectively.

[0109] The present application has been described in connection with various embodiments and implementations as examples and implementations. However, other variations can be understood and effected by those skilled in the art in practising the claimed subject matter from the further claims and the description presented herein, which forms a part of the disclosure. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit can fulfil the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A hardware device (100) for frame arbitration in a network entity (300), characterized in that, The hardware device (100) comprises: N ingress ports (101) for receiving N frames (102), wherein N > 1; M egress ports (103) for outputting M frames (102), wherein M > 1; processing circuitry (105) connected to the ingress ports (101) and the egress ports (103); wherein each frame (102) comprises a frame header (201) comprising a frame priority field (202), wherein the frame priority field (202) comprises a set of bits, and wherein the set of bits comprises two or more subsets of bits, each subset of bits indicating a respective arbitration metadata; and wherein the processing circuitry (105) is configured to, when at least a first frame (102a) and a second frame (102b) are simultaneously received at the ingress ports (101): determine, based on the set of bits in the frame priority field (202) of the first frame (102a) and the second frame (102b), respectively, which one of the first frame (102a) and the second frame (102b) is to be processed and output at the egress ports (103) sequentially or concurrently in a next clock cycle.

2. The hardware device (100) according to claim 1, characterized in that, The processing circuitry (105) is configured to update the set of bits in the frame priority field (202) of each frame (102) before the frame (102) is processed and output at the egress ports (103).

3. The hardware device (100) according to claim 2, characterized in that, The set of bits in the frame priority field (202) of the frame (102) is updated based on information contained within the frame (102) and / or based on available information of the network environment and the hardware device (100) itself.

4. The hardware device (100) according to claim 2 or 3, characterized in that, The set of bits in the frame priority field (202) of the frame (102) is updated based on at least one of: a state of a queue in which the frame (102) is received; a timeout and / or a timestamp of the frame (102); a list of one or more network processing tasks to be performed on the frame (100); a state of one or more hardware accelerators, wherein one or more network processing tasks have to be performed on the frame (102) before the frame (102) is outputted; a state of a time sensitive network shaper of the frame (102) to be outputted; an in-band telemetry state; a virtual local area network tag priority of the frame (102).

5. The hardware device (100) according to any one of claims 1 to 4, characterized in that, Each frame (102) comprises an instruction frame (203) and a data frame (204), wherein the frame header (201) comprising the frame priority field (201) belongs to the instruction frame (203).

6. The hardware device (100) according to claim 5, characterized in that for: receiving and outputting each instruction frame (203) in a control plane; receiving and outputting each data frame (204) in a data plane.

7. The hardware device (100) according to any one of claims 1 to 4, characterized in that, The processing circuitry (105) is configured to separate each frame (102) received at the ingress ports (101) into an instruction frame (203) and a data frame (204), wherein the instruction frame (203) is provided with the frame header (201) comprising the frame priority field (202).

8. The hardware device (100) according to any one of claims 5 to 7, characterized in that, The processing circuitry (105) is further configured to, prior to outputting the frames (102) at the egress port (103), process the data frame (204) of each frame (102) according to instructions comprised in the frame header (201) of the frame (200) and a payload (205) of the instruction frame (203).

9. The hardware device (100) according to any one of claims 1 to 8, characterized in that, The processing circuitry (105) is configured to: associate weights with the subset of bits in the frame priority field (202) of each frame (102); determine, in the next clock cycle, which of the first frame (102a) and the second frame (102b) is output at the egress port (103) by executing a sorting algorithm further based on the weights respectively associated with the subset of bits in the frame priority field (202) of the first frame (102a) and the second frame (102b).

10. The hardware device (100) according to claim 9, characterized in that, The processing circuitry (105) comprises: a set of configurable multiplexers (800), wherein different configurations of the set of configurable multiplexers (800) correspond to different weights associated with the subset of bits in the frame priority field (202) of each frame (102).

11. The hardware device (100) of any of claims 1 to 10, wherein the N ingress ports (101) are connected to N or more parallel queues for providing the N ingress frames (102) in parallel from the N ingress ports (101); and / or the M egress ports (103) are connected to M or more parallel queues for receiving M of the egress frames (102) in parallel and sending them in parallel to the M egress ports (102).

12. An instruction frame (203) characterized by a frame format suitable for frame arbitration in a network entity, the frame format comprising: a frame header (201); wherein the frame header (201) comprises a frame priority field (202); wherein the frame priority field (202) comprises a set of bits; wherein the set of bits comprises two or more subsets of bits; and wherein each subset of bits indicates respective arbitration metadata.

13. The instruction frame (203) according to claim 12, characterized in that The respective arbitration metadata comprises one or more bits indicating a priority of the instruction frame (203).

14. The instruction frame (203) according to claim 12 or 13, characterized in that, The respective arbitration metadata further comprises at least one of: one or more bits indicating a queue status of a queue providing the instruction frame (203); one or more bits indicating a timeout or timestamp of the instruction frame (203); one or more bits indicating a list of one or more processing tasks to be performed on the instruction frame (203); one or more bits indicating a status of one or more hardware accelerators on which one or more network processing tasks have to be performed on the instruction frame (203); one or more bits indicating a time sensitive network shaper of the instruction frame (203); one or more bits indicating an in-band telemetry status; one or more bits indicating a virtual local area network tag priority of the instruction frame (203).

15. The instruction frame (203) according to any one of claims 12 to 14, characterized in that, The frame priority field (202) is a first field in the frame header (201).

16. The instruction frame (203) according to any one of claims 12 to 15, characterized in that, The frame format is based on one of the following protocols: - controller area network (CAN); - CAN flexible data rate; - CAN XL; - local interconnect network; - FlexRay; - media oriented systems transport; - Ethernet; - mobile industry processor interface; - camera serial interface 2.

17. The instruction frame (203) according to any one of claims 12 to 16, characterized in that, The frame format is a standardized frame format comprising a plurality of fields, wherein each field is parameterized by a field index or offset parameter and a field size parameter.

18. The instruction frame (203) according to any one of claims 12 to 17, characterized in that, Further comprising a payload (205), wherein the frame header (201) and the payload (205) comprise instructions indicating how a data frame (204) associated with the instruction frame (203) is to be processed by a processing circuitry (105) of the hardware device (100).

19. A method (900) for frame arbitration in a network entity (300), characterized by, The method (900) is performed by a hardware device (100) and comprises: receiving (901) at least a first frame (102a) and a second frame (102b) simultaneously at a plurality of ingress ports (101) of the hardware device (100); wherein each frame (102, 102a, 102b) comprises a frame header (201) comprising a frame priority field (202), wherein the frame priority field (202) comprises a set of bits, and wherein the set of bits comprises two or more subsets of bits, each subset of bits indicating a respective arbitration metadata; and determining (902), by a processing circuitry (105) of the hardware device (100), which one of the first frame (102a) and the second frame (102b) is to be processed and output sequentially or concurrently at a plurality of egress ports (103) of the hardware device (100) in a next clock cycle based on the set of bits in the frame priority field (202) of the first frame (102a) and the second frame (102b), respectively.

Images