Adaptive traffic arbitration engine

Abstract

The present invention relates to frame arbitration in a network entity, e.g., for data forwarding, switching, routing or gateway. 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 presented. The hardware device comprises an Ngt for receiving N frames; the input port is used for outputting Mgt of M frames; an input port, an output port, and a processing circuit connected to the input port and the output port. Each frame includes a frame header containing a frame priority field, the frame priority field including a bit set containing two or more subsets of bits, each subset of bits indicating arbitration metadata. The processing circuitry is to determine which one of a first frame and a second frame is processed and output at the egress port in a next clock cycle based on the frame priority field when the first frame and the second frame are simultaneously received.

Description

Technical Field

[0001] The present invention relates to network traffic arbitration in a network entity, wherein the network traffic is processed in frames. The network entity may be used for data forwarding, switching, routing or gateway in a communication network. The present invention proposes a hardware device for frame arbitration in a network entity. In addition, the present invention proposes a frame having a frame format suitable for frame arbitration and a method for performing frame arbitration. Background Art

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

[0003] Arbitration strategies can become complex with respect to timing requirements, especially in network entities with a significant number of high-speed ingress and egress ports that must handle a large volume of network traffic, at least part of which is critical with respect to functional safety and / or timing determinism requirements. This is the case, for example, for future 100Mbps, 1000Mbps, or even multi-Gigabit automotive Ethernet networks.

[0004] Software-centric approaches may result in data throughput bottlenecks and design challenges that are difficult to overcome. In addition, software-centric approaches may not scale well due to their complexity. Summary of the invention

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

[0006] These and other objects are achieved by what is described in the independent claims. Advantageous implementations are further described in the dependent claims.

[0007] A first aspect of the present invention provides a hardware device for frame arbitration in a network entity, the hardware device comprising: N input ports for receiving N frames, wherein N>1; M output ports for outputting M frames, wherein M>1; a processing circuit connected to the input ports and the output ports; wherein each frame comprises a frame header containing a frame priority field, wherein the frame priority field comprises a bit set, and wherein the bit set comprises two or more bit subsets, each bit subset indicating corresponding arbitration metadata; and wherein the processing circuit is used to determine which of the first frame and the second frame to be processed and output sequentially or concurrently at the output port in the next clock cycle when at least a first frame and a second frame are received simultaneously at the input port: based on the bit sets in the frame priority fields of the first frame and the second frame respectively.

[0008] According to the first aspect, the present invention proposes a hardware-centric solution for frame arbitration in a network entity, rather than a software-centric solution. The hardware-centric solution can reduce the complexity level in programming. The solution of the present invention also has better scalability and can achieve better performance levels (for example, in terms of key performance indicators (KPIs) including frame delay and jitter or in terms of data throughput passing through the network entity) than conventional software-centric solutions. The hardware-centric solution of the present invention can automate all routing and forwarding processes that are assigned to the network entity at different processing levels.

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

[0010] The hardware device of the first aspect can provide a completely autonomous frame arbitration scheme that operates exclusively in hardware without any software intervention. It should be noted that the software in the present invention is understood as executing machine instructions described by source code through a processor such as a CPU. In the present invention, the hardware device is responsible for the arbitration of frames from the ingress port to the egress port without the need for such machine instructions.

[0011] Each frame may require a different type of processing task, and the hardware device may be able to perform these different types of processing tasks on the frames in parallel. Frame arbitration may include allocating the frames received at the ingress port to the required processing tasks. The processing tasks may be performed by one or more processing resources of the hardware device, such as one or more hardware accelerators. Any frame may also be associated with two or more processing tasks that must be completed sequentially, such as according to a specific processing order. In this case, the frame may be processed by performing one processing task after another according to a certain 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 must be performed by the same one or more processing resources, the frame arbitration may be performed by the hardware device. In this case, according to the determination of the processing circuit of the hardware device, one of the first frame and the second frame may appear before the other frame, and the other frame may wait, for example, in a queue until the processing resource is free again after processing the first frame. In this way, the frame arbitration may take effect, and the processing circuit may decide which of the two frames competing for the same one or more processing resources has a higher priority.

[0013] In an implementation of the first aspect, the processing circuit 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 as described in the first aspect that is also designated to process the one or more frames (output by the hardware device of the first aspect) may use the one or more updated frame priority fields for further frame arbitration. For example, each of the multiple processing stages of the network device may include a hardware device according to the first aspect, and each hardware device may perform frame arbitration for its associated processing stage based on the frame priority field in the frame it receives at its ingress port.

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

[0016] The available information may include at least one of a status of the network and a status of the hardware device.

[0017] In an implementation 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 state of a queue receiving the frame; a timeout and / or 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 must be performed on the frame before the frame is output; a state of a time-sensitive network shaper for the frame to be output; an in-band telemetry state; and a virtual local area network tag priority of the frame.

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

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

[0020] In an implementation of the first aspect, the processing circuit is used to separate each frame received at the ingress port into an instruction frame and a data frame, wherein the instruction frame has the frame header including the frame priority field.

[0021] According to the above implementations respectively describing the instruction frame and the data frame, the solution of the present invention supports a software defined networking (SDN) approach, which means separation into the data plane and the control plane.

[0022] In an implementation of the first aspect, the processing circuit is further configured to process the data frame of each frame according to instructions included 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 included in the instruction frame can be processed by the hardware device to control the processing of the data frame. For example, the processing circuit of the hardware device can automatically process the data frame based on the instruction bits of the instructions included in the instruction frame without any software interaction. Therefore, the processing circuit can also arbitrate the processing of different data frames based on the bit sets in the corresponding frame priority information fields associated with different data frames in the instruction frame.

[0024] In an implementation of the first aspect, the processing circuit is used to associate weights with the bit subsets in the frame priority field of each frame; and further determine which one of the first frame and the second frame to output at the output port in the next clock cycle based on the weights associated with the bit subsets in the frame priority fields of the first frame and the second frame, respectively, and by executing a sorting algorithm.

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

[0026] In an implementation of the first aspect, the processing circuit includes 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, based on weighted bit subsets in the frame priority fields of the first frame and the second frame, the multiplexer can automatically determine which of the first frame and the second frame to process and output first at the egress port in the next clock cycle.

[0028] In an implementation 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 must wait for processing due to the frame arbitration may be retained in the queue. For example, the hardware device may receive parallel frames at an ingress port, may provide them to the parallel queue, and may select them one by one from the parallel queue for processing based on the frame priority field. For example, the hardware device may provide processed frames to the parallel queue, and may further output the frames from the queue at the egress port.

[0030] A second aspect of the present invention provides an instruction frame, which has a frame format suitable for frame arbitration in a network entity, and the frame format includes: a frame header; wherein the frame header includes a frame priority field; wherein the frame priority field includes a bit set; wherein the frame priority field includes a bit set, wherein the bit set includes two or more bit subsets, and wherein each bit subset indicates corresponding arbitration metadata.

[0031] The instruction frame of the second aspect, in particular the frame priority field, implements the hardware-centric solution of the present invention for the frame arbitration, as implemented by the hardware device of the first aspect. Therefore, the frame format of the instruction frame produces the advantages described above for the hardware device.

[0032] In an implementation of the second aspect, the corresponding arbitration metadata includes one or more bits indicating a priority of the instruction frame.

[0033] Therefore, in the case where the same processing resources must be used for the two or more frames, for example, the two or more frames are processed one by one according to their priorities by the processing circuit of the hardware device of the first aspect.

[0034] In an implementation of the second aspect, the corresponding arbitration metadata also includes at least one of the following: 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 must 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 an implementation of the second aspect, the frame priority field is the first field in the frame header.

[0036] This facilitates fast response and thus facilitates processing efficiency of the hardware device that processes the frame in, for example, the first aspect.

[0037] In an implementation 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 System 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 an implementation 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 network entities (such as automotive gateways) to efficiently handle the various network protocols used together.

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

[0042] A third aspect of the present invention provides a method for frame arbitration in a network entity, which is performed by a hardware device and includes: simultaneously receiving at least a first frame and a second frame at multiple input ports of the hardware device; wherein each frame includes a frame header containing a frame priority field, wherein the frame priority field includes a bit set, and wherein the bit set includes two or more bit subsets, each bit subset indicating corresponding arbitration metadata; and determining, by the processing circuit of the hardware device, which one of the first frame and the second frame is to be processed and output sequentially or concurrently at multiple output ports of the hardware device in the next clock cycle based on the bit sets in the frame priority fields of the first frame and the second frame, respectively.

[0043] In an implementation of the third aspect, the processing circuit 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 of the third aspect, the bit set in the frame priority field of the frame is updated based on information contained in the frame and / or based on a network environment and available information of the hardware device itself.

[0045] In an implementation 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 receiving the frame; a timeout and / or 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 must be performed on the frame before the frame is output; a state of a time-sensitive network shaper for the frame to be output; an in-band telemetry state; and a virtual local area network tag priority of the frame.

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

[0047] In an implementation 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 an implementation of the third aspect, the processing circuit separates each frame received at the ingress port into an instruction frame and a data frame, wherein the instruction frame has the frame header including the frame priority field.

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

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

[0051] In an implementation 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 invention can be applied to any type of network entity, such as switches, smart network interface cards (NICs), routers, and gateways. The hardware device implements frame arbitration within the network entity to achieve 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 the startup configuration). The fact that the hardware device does not need to be processed by a CPU executing source code lines improves performance and time determinism and other quality of service (QoS) indicators.

[0054] The hardware device may be synthesized in silicon, may conform to the SDN network architecture at the device level, and may be distributed on the control plane and the data plane of the network entity. The processing circuit of the hardware device may perform the network traffic arbitration in a distributed manner at different processing levels of the network entity (e.g., processing levels for frame priority supervision, queuing or dequeuing, processing and / or shaping). Therefore, due to the optimized hardware architecture of the hardware device, virtually no overhead in terms of latency, jitter, and consumption of resources is generated.

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

[0056] The hardware device may be controlled by the bit set in the frame priority field of the frame, wherein the arbitration metadata (a subset of bits) in the bit set may be based on a large and diverse set of inputs, some of which are static and may be (re)configurable via a set of registers (e.g., a memory map) of the hardware device, and other inputs are dynamically updated by the hardware device itself, e.g., 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 priorities given to the bits of the bit set may result in a diverse and flexible set of operating modes for the hardware device.

[0057] It should be noted that the hardware device is also referred to as a “distributed arbitration engine (DAE)” in the present invention.

[0058] It should be noted that all devices, elements, units and devices described in this application can be implemented as hardware elements. All steps performed by various entities described in this application and the functions to be performed by various entities described are intended to refer to the corresponding entities for performing the corresponding steps and functions. Even in the description of the following specific embodiments, the specific functions or steps to be performed by the external entity are not reflected in the description of the specific detailed elements of the entity performing the specific steps or functions, but for the technician, these methods and functions can be implemented in the corresponding hardware elements. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] In conjunction with the accompanying drawings, the following description of specific embodiments will illustrate the above aspects and their implementation methods. In the drawings:

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

[0061] Figure 2 A command frame having a frame format suitable for frame arbitration according to the present invention is shown.

[0062] Figure 3 An exemplary architecture of a network entity (specifically, an automotive gateway controller) is shown, in which the hardware device according to the present invention is deployed.

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

[0064] Figure 5 The decoupling of the control plane and the data plane across an exemplary network entity 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 in an automotive gateway controller.

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

[0068] Fig. 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 to perform 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 include a processing circuit 105, and this processing circuit 105 can be installed in the network entity. For example, the processing circuit 105 can be deployed in the network entity in a distributed manner. For example, the processing circuit 105 can be included in one or more processing stages of the network entity. Each processing stage of the network entity can be used to perform one or more processing tasks on one or more frames.

[0070] Processing circuit 105 may be responsible for executing, performing or initiating various operations of hardware device 100 described in the present invention. Processing circuit 105 may include analog circuits, digital circuits, or both analog circuits and digital circuits. Digital circuits may include components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. Hardware device 100 may also include memory circuits for storing information. For example, hardware device 100 may include one or more queues, such as one or more first in first out (FIFO) memories for storing and arranging frames, for example, between processing stages.

[0071] In addition to the processing circuit 105, the hardware device 100 also 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 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 set of bits. This set of bits 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. Alternatively, 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 by the dashed box in Figure 2 , 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 can also 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 when at least a first frame 102a and a second frame 102b are received simultaneously at the input port 101 (where both are frames 102, for example as shown in Figure 2102a and 102b), it is determined which of the first frame 102a and the second frame 102b is to be processed and outputted (sequentially or concurrently) at the egress port 103 in the next clock cycle. That is, the processing and outputting 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 sets 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, and can also process the bit set in the frame priority field 202 of the second frame 102b. Based on this, 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, which 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 a subset of bits in the frame priority field 202. The determination step of the processing circuit 105 does not require software or a processor based on software or machine instructions. By performing the determination step, at least the frame arbitration between the first frame 102a and the second frame 102b is achieved. Of course, the determination step can be based on any two frames 102 received at the ingress port 101 at the same time, for example, from two or more parallel queues connected to the ingress port 101. It can also be performed for more than two frames 102 received in parallel. Therefore, the hardware device 100 is suitable for frame arbitration, usually 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 an automobile gateway, which includes the hardware device 100. Specifically, the hardware device 100 can be implemented in a gateway controller of the gateway. It should be noted that the network entity 300 can also be of different types, for example, the network entity 300 can be an intelligent network interface card (NIC), a switch or a router.

[0078] Also like Figure 3 As shown, the network entity 300 may include multiple processing stages. For example, in an exemplary case, the network entity 300 may include four processing stages. Figure 3102. The processing stages of network entity 300 are referred to as "frame normalizer," "filtering and policing," "gateway (signaling and PDU)," and "traffic shaping," respectively. Each processing stage of network entity 300 may be used to perform one or more different processing tasks on each frame 102. Frame 102 may follow a data path through network entity 300 that directs frame 102 through each of the plurality of processing stages.

[0079] Hardware device 100 Figure 3 The processing circuit 105 of the hardware device 100 may be located in each processing stage of the network entity 300. The processing circuit 105 of the hardware device 100 may be distributed across these processing stages.

[0080] In one example, if Figure 3 As can be seen in FIG. 1 , each processing stage may include at least one DAE. Thus, one or more DAEs of each respective processing stage may be considered to form a DAE as described above with respect to FIG. Figure 1 The hardware device 100 described herein may be a distributed hardware device 100. In this case, the ingress port of the corresponding processing stage may correspond to the ingress port 101 of the hardware device 100, and in this case, the egress port of the corresponding processing stage may correspond to the egress port 103 of the hardware device 100. Nevertheless, one or more DAEs deployed in each of the multiple processing stages of the network entity 300 may also be considered to form a distributed hardware device 100. In this case, the ingress port of the network entity 300 may correspond to the ingress port 101 of the hardware device 100, and the egress port of the network entity 300 may correspond to the egress port 103 of the hardware device 100. Such a distributed implementation of the processing circuits 105 across the processing stages of the network entity 300 may have only a negligible overhead in terms of hardware resources, and virtually no penalty for delay or jitter of frames.

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

[0082] In general, all frames 102 provided to the ingress port of the network entity 300 in parallel and / or subsequently may flow through all processing stages of the network entity 300, may be processed by each processing stage, and may then be output in parallel and / or subsequently at the egress port of the network entity 300. The processing circuitry 105 of one or more hardware devices 100 may decide which frames 102 need to be processed by which processing resources of the processing stages and at what time, wherein all these decisions may be made based on priority criteria encoded into the corresponding frame priority fields 202 of the frames 102. Optionally, these frame priority fields 202 may 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 may be changed or reconfigured.

[0083] like Figure 4 As shown, inspired by the SDN approach, the processing circuit 105 of the hardware device 100 can be used to separate each frame 102 received at its ingress port 101 into an instruction frame 203 and a data frame 204, as shown in FIG. Figure 2 For example, in Figure 3 , each frame 102 input to the first processing stage (“frame normalizer”) of the network entity 300 can be decomposed into an instruction frame 203 and a data frame 204 in this manner by the processing circuit 105 disposed in this processing stage. The instruction frame 203 can contain arbitration metadata in the frame priority field 202, and can contain additional metadata, such as metadata of the original frame 102. The data frame 204 can basically contain the payload of the original frame 102.

[0084] The processing circuit 105 of the hardware device 100 may also be used to receive and output the instruction frame 203 in the control plane, and receive and output the data frame 204 in the data plane. In this case, the processing circuit 105 may not need to perform separation. That is, the processing circuit 105 may receive, process and output the frame 102 in an already separated manner (such as Figure 2 For example, in Figure 3 In the embodiment, after the frame 102 is separated in the processing stage, the processing circuit 105 in one or more subsequent processing stages may process the instruction frame 203 including the frame priority field 202 and the data frame 204 in the control plane and the data plane, respectively.

[0085] In other words, each frame 102 may first be regenerated in the network entity 300 into an instruction frame 203 and a data frame 204, and from this step, the instruction frame 203 may be provided with a frame priority field 202 describing the priority assigned to this frame 102 (specifically the data frame 204). The frame priority field 202 may be used to perform arbitration with other frames 102 in each processing stage of the network entity 300. For example, the processing circuit 105 in each processing stage may determine which frame 102 of two or more frames stored in a queue before the processing stage may be first selected for processing in the processing stage. This frame arbitration is performed based on the priority levels of the frames 102 queued in parallel, which are determined by the bit sets in their corresponding frame priority fields 202. These priority levels are determined by arbitration metadata encoded into the frame header 201.

[0086] Therefore, 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 beneficial for efficiency (implementation and execution). In this case, the frame priority field 202 can be the first field read by the processing circuit 105, so that the frame is read without forcing the frame to leave the queue, and an immediate response can be given (in only one clock cycle).

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

[0088] By the method of the present invention, Figure 5 As shown, a fully SDN layered network entity 300 can be obtained, which can be driven by arbitration metadata in the frame header 201 of the frame 102, specifically the arbitration metadata in the frame priority field 202. Figure 5As can be seen in FIG. 1 , the format of the frame 102 can be based on various network protocols. For example, the protocol can be CAN, CAN Flexible Data Rate, CAN XL, Local Interconnect Network, FlexRay, Media Oriented System Transport, Ethernet, Mobile Industry Processor Interface, or Camera Serial Interface 2. For example, the frame arbitration of the present invention 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 may be transferred from one processing stage to the next in the network entity 300. Each processing stage may process the data frame 204 according to the instructions in the instruction frame 203, and may process the instruction frame 203 to move and / or update the frame priority field 202 and optionally other metadata. This may be accomplished, for example, by the processing circuitry 105 of one or more hardware devices 100 deployed in a distributed manner in the processing stages. Processing and optionally modifying or updating the arbitration metadata in the frame priority field 202 of each processed frame 102 may be accomplished at runtime.

[0090] In order to provide the best possible arbitration strategy within the network entity 300, each frame 102 may be provided with different arbitration metadata, which may be organized in one or more information fields of the frame priority field 202. In terms of arbitration strategy, the following factors may participate in inline priority assignment via the frame priority field 202 of the frame 102. In the following example, the frame priority field 202 may 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 being processed or hardware accelerator status [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 digits: level]

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

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

[0099] like Figure 6 As can be seen in FIG. 1 , the selection of the next frame 102 to be processed is completed 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. The instruction frame 203 and the data frame 204 can both be stored in the parallel FIFO. The processing circuit 105 of the hardware device 100 can control at least one multiplexer to process the data frame 204 in the order determined based on the instruction frame 203.

[0100] Figure 7 shows an exemplary architecture of the processing circuit 105 of the hardware device 100, Figure 7 by Figure 6 Based on, it is shown that the processing circuit 105 can arbitrate the frame 102 according to the frame priority field 202 in the instruction frame 203 of the frame 102, so that the corresponding data frame 204 of the 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. 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. FIFO can also be used to store the corresponding instruction frame 203.

[0101] The frame priority field 202 of any frame 102 may be adapted by runtime reconfiguration (e.g., on the fly). This may be accomplished by one or more hardware multiplexers 800, such as Figure 8 As shown. For example, the hardware device 100 may include a set of configurable multiplexers 800. The hardware device 100 may also be configured 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 in FIG. 8 , multiplexing can reorder the weights associated with a 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. Therefore, the frame priority field 202 is adjusted or reconfigured. Self-reconfiguration (by the hardware device 100) and (re)configuration can be performed on the fly, for example, by the host CPU, without interrupting the operation of the network entity 300. This powerful feature provides the possibility for different operating modes. The relative priority given to each frame 102 can be configurable accordingly 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 so that higher weights are preferred (little endian mode): for example, MSB to LSB.

[0102] Frame arbitration performed based on processing of the frame priority field 202 by the processing circuit 105 can be based on an ordering of the bit sets (e.g., according to a resulting value based on a weight assigned to each bit). A simple algorithm can be implemented (to reduce complexity), and an efficient and cost-effective arbitration scheme implemented in hardware can be achieved. Each frame 102 can be appropriately identified and prepared for arbitration by the hardware device 100, wherein self-contained arbitration metadata is stored in the instruction frame 203. For example:

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

[0104] Frame arbitration may also take into account the status of one or more hardware accelerators and one or more internal queues of the network entity 300, for example, to improve QoS (e.g., avoiding unnecessary discarding of messages in a queue) and / or optimize the use of shared hardware resources (e.g., management, scheduling, and reuse (loopback) of processing tasks in switching, routing, or gateway functions 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 independent (due to SDN and decoupling achieved through instruction frame 203). The protocol independent arbitration strategy may be a driving factor for improving 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] Fig. 9A method 900 is shown that can be used for frame arbitration in a network entity 300 according to the present invention. The method 900 is performed by a 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 a plurality of ingress ports 101 of the hardware device 100. Each frame 102, 200 comprises a frame header 201 including a frame priority field 202, wherein the frame priority field 202 comprises a bit set, wherein the bit set comprises two or more bit subsets, and wherein each bit subset indicates corresponding arbitration metadata.

[0108] The method 900 also includes step 902: determining, through the processing circuit 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 multiple output ports 103 of the hardware device 100 in the next clock cycle based on the bit sets in the frame priority fields 202 of the first frame 102a and the second frame 102b, respectively.

[0109] The invention has been described in conjunction with various embodiments as examples and implementations. However, from a study of the drawings, the invention and the independent claims, other variations will be understood and implemented by those skilled in the art in implementing the claimed subject matter. In the claims and in the specification, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" does not exclude a plurality. A single element or other unit may fulfil the functions of several entities or items described in the claims. The listing of certain measures in mutually different dependent claims does not indicate that a combination of these measures cannot be effectively used.

Claims

1. A hardware device (100) for frame arbitration in a network entity (300), characterized in that: The hardware device (100) comprises: N input ports (101) for receiving N frames (102), where N>1; M output ports (103), used to output M frames (102), where M>1; A processing circuit (105) connected to the input port (101) and the output port (103); wherein each frame (102) comprises a frame header (201) comprising a frame priority field (202), wherein the frame priority field (202) comprises a bit set, and wherein the bit set comprises two or more bit subsets, each bit subset indicating corresponding arbitration metadata; and The processing circuit (105) is configured to, when at least a first frame (102a) and a second frame (102b) are simultaneously received at the ingress port (101): Based on the bit sets in the frame priority fields (202) of the first frame (102a) and the second frame (102b), respectively, it is determined which of the first frame (102a) and the second frame (102b) is to be processed and output sequentially or concurrently at the output port (103) in the next clock cycle.

2. The hardware device (100) according to claim 1, characterized in that: The processing circuit (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 port (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 network conditions and available information of 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: the state of the queue receiving the frame (102); a timeout and / or 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 must be performed on the frame (102) before the frame (102) is output; a state of a time-sensitive network shaper of said frame (102) to be output; In-band telemetry status; The 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) includes an instruction frame (203) and a data frame (204), wherein the frame header (201) including the frame priority field (201) belongs to the instruction frame (203).

6. The hardware device (100) according to claim 5, characterized in that: Used for: Receiving and outputting each command frame in the control plane (203); Each data frame (204) is received and output in the data plane.

7. The hardware device (100) according to any one of claims 1 to 4, characterized in that: The processing circuit (105) is used to separate each frame (102) received at the ingress port (101) into a command frame (203) and a data frame (204), wherein the command frame (203) has the frame header (201) including the frame priority field (202).

8. The hardware device (100) according to any one of claims 5 to 7, characterized in that: The processing circuit (105) is also used to process the data frame (204) of each frame (102) according to the instructions included in the frame header (201) of the frame (200) and the payload (205) of the instruction frame (203) before outputting the frame (102) at the output port (103).

9. The hardware device (100) according to any one of claims 1 to 8, characterized in that: The processing circuit (105) is used for: associating a weight with said subset of bits in said frame priority field (202) of each frame (102); Further based on the weights associated with the bit subsets in the frame priority fields (202) of the first frame (102a) and the second frame (102b), respectively, a sorting algorithm is executed to determine which of the first frame (102a) and the second frame (102b) is output at the output port (103) in the next clock cycle.

10. The hardware device (100) according to claim 9, characterized in that: The processing circuit (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) according to any one of claims 1 to 10, characterized in that: The N ingress ports (101) are connected to N or more parallel queues, the N or more parallel queues being used to provide 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, and the M or more parallel queues are used to receive M egress frames (102) in parallel and send them to the M egress ports (102) in parallel.

12. A command frame (203), characterized in that: A frame format suitable for frame arbitration in a network entity, the frame format comprising: Frame header (201); Wherein, the frame header (201) includes a frame priority field (202); wherein the frame priority field (202) comprises a bit set; wherein the bit set includes two or more bit subsets; and Each bit subset indicates corresponding arbitration metadata.

13. The instruction frame (203) according to claim 12, characterized in that: The corresponding arbitration metadata includes 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 corresponding arbitration metadata further includes at least one of the following: 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, wherein one or more network processing tasks must 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 the status of in-band telemetry; One or more bits indicating the 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 the 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 interconnection network; -FlexRay; -Media oriented system transmission; - 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: Also included is a payload (205), wherein the frame header (201) and the payload (205) include instructions indicating how a data frame (204) associated with the instruction frame (203) is to be processed by a processing circuit (105) of the hardware device (100).

19. A method (900) for frame arbitration in a network entity (300), characterized in that: 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 bit set, and wherein the bit set comprises two or more bit subsets, each bit subset indicating corresponding arbitration metadata; and The processing circuit (105) of the hardware device (100) determines (902) which of the first frame (102a) and the second frame (102b) is to be processed and output sequentially or concurrently at the multiple output ports (103) of the hardware device (100) in the next clock cycle based on the bit sets in the frame priority fields (202) of the first frame (102a) and the second frame (102b).

Images