Synchronization of the quality of service configuration within a cluster of network devices with a leaf-backbone topology

Abstract

A computer program product comprising a non-transitory, computer-readable medium that stores a set of instructions for synchronizing the Quality of Service (QoS) configuration within a cluster of network devices with a leaf-backbone topology; wherein the set of instructions, when executed by a computer-controlled circuit, causes the computer-controlled circuit to: to provide the QoS configuration within a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; to establish communication pathways between the first leaf device and other leaf devices of the number of leaf devices; and to provide the QoS configuration from the first leaf device through the communication channels to the other leaf devices in order to synchronize the QoS configuration with the other leaf devices of the number of leaf devices.

Description

BACKGROUND

[0001] A multilayered cell-based network can exhibit a backbone-leaf architecture. In such a network, a first layer of leaf devices connects to hosts, and one or more other layers of spine devices connect to the first layer of leaf devices.

[0002] When a sending host sends a packet across the network to a receiving host, an input leaf device receives the packet, splits it into fabric cells, and sends (or distributes) the fabric cells evenly across the backbone devices. The backbone devices then forward the fabric cells to an output leaf device, which reassembles the packet from the fabric cells and delivers the reassembled packet to the receiving host. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The foregoing and other objectives, features, and advantages will become apparent from the following description of certain embodiments of the present disclosure, as illustrated in the accompanying drawings, in which the same reference numerals in the different views refer to the same parts. The drawings are not necessarily to scale but rather serve to illustrate the principles of various embodiments of the present disclosure. Fig. Figure 1 is a diagram of an electronic environment that supports the synchronization of the Quality of Service (QoS) configuration according to one or more embodiments. Fig. Figure 2 is a diagram showing the QoS configuration synchronization from an output leaf device to input leaf devices according to one or more embodiments. Fig. Figure 3 is a diagram of at least one section of a sheet device according to one or more embodiments. Fig. Figure 4 is a diagram of at least sections of leaf devices during QoS configuration synchronization according to one or more embodiments. Fig. Figure 5 is a flowchart of a process performed by a first-leaf device during QoS configuration synchronization according to one or more embodiments. Fig. Figure 6 is a flowchart of a procedure performed by a second-sheet device during QoS configuration synchronization according to one or more embodiments. Fig. Figure 7 is a diagram showing the QoS configuration synchronization from an input leaf device to output leaf devices according to one or more embodiments. Fig. Figure 8 is a diagram showing the QoS configuration by a central device according to one or more embodiments. DETAILED DESCRIPTION Overview

[0004] To manage potential congestion situations, Quality of Service (QoS) policies can be imposed on individual interfaces. For example, a QoS policy such as Early Congestion Notification (ECN) or Weighted Random Early Drop (WRED) can be applied to an interface of an outbound leaf device that delivers packets to a receiving host. When ECN is applied to the interface, a packet delivered by the interface to the receiving host will have a congestion notification bit that is set when the network experiences certain high traffic loads (e.g., when the remaining buffer capacity falls below a threshold). When WRED is applied to the interface, one or more packets en route to the receiving host can be dropped to maintain network stability (e.g., to prevent network congestion).(to prevent buffer overflow). Other QoS policies are also suitable for use.

[0005] It is understood that the network's leaf devices can use separate operating system instances and separately deployed QoS policy settings. It is further understood that while it may be advantageous to initially deploy QoS policy settings for the outbound leaf device, which has the interface delivering packets to the receiving host, the components for imposing the QoS policy for that interface can reside in the other leaf devices of the backbone leaf network. For example, in the context of ECN, a packet's congestion notification bit for the receiving host would be set by the inbound leaf device when the inbound leaf device reaches a certain level of congestion (e.g., based on the remaining buffer capacity within the inbound leaf device).Similarly, in the context of WRED, the entry leaf device would be the point where a packet is intentionally dropped to ensure network stability. Therefore, a procedure is needed to effectively coordinate the deployment of QoS policy settings for a leaf device interface among leaf devices in a backbone leaf network.

[0006] The aforementioned need is at least partially met by a method that involves synchronizing the QoS configuration for one or more interfaces within a cluster of network devices with a leaf-backbone topology. For example, for a specific interface of a particular output leaf device delivering packets to a specific host device, the technique might involve deploying the QoS configuration for that interface within an initial leaf device, such as the output leaf device, and then deploying the QoS configuration from the initial leaf device to the other leaf devices in the cluster to synchronize the QoS configuration for that interface across the cluster of network devices with the leaf-backbone topology.A similar technique can be applied to another interface to synchronize the QoS configuration for multiple interfaces or even for all interfaces of the entire cluster.

[0007] In the example above, the QoS configuration can be moved from the output leaf device to other leaf devices that can act as input leaf devices, receiving packets from the other hosts and delivering them to the specific host device. However, it should be noted that the techniques are also suitable for transferring the QoS configuration from an input leaf device to one or more output leaf devices.

[0008] Furthermore, it should be noted that several techniques disclosed herein offer a simplification of operation, whereby the QoS configuration initially remains in a "possessing" node and is then propagated from the possessing node to other relevant nodes within the cluster. Since the QoS configuration in the example above applies to an interface of the specific leaf device, the specific leaf device can be considered the "natural" associated node of the QoS configuration, and the techniques allow the QoS configuration to be made available to other relevant leaf devices to synchronize the QoS configuration within the cluster.

[0009] It is understood that the cluster can be operated as a Distributed Etherlink Switch (DES) system, supporting large-scale computing environments such as those used for artificial intelligence (AI), machine learning (ML), data centers, enterprise campuses, etc. Furthermore, QoS synchronization can be performed at the start of cluster operation and / or at any time during cluster operation.

[0010] The various individual features of the particular arrangements, configurations, and embodiments disclosed herein may be combined in any desired manner that is technologically sensible. Furthermore, such features are hereby combined in this manner to form all possible combinations, variants, and permutations, except to the extent that such combinations, variants, and / or permutations have been expressly excluded or are impractical. Support for such combinations, variants, and permutations is deemed to be provided in this document. Environmental details

[0011] Fig. Figure 1 shows an electronic environment 100 that supports the synchronization of the Quality of Service (QoS) configuration according to one or more embodiments. Such synchronization is a way to effectively coordinate the provisioning of QoS policy settings for a leaf-device interface among leaf devices of a backbone-leaf network.

[0012] The electronic environment 100 comprises host devices 110(a), 110(b), ... (collectively referred to as host devices 110), a cluster of network devices (or simply cluster) 120, and link segments 130 connecting the host devices 110 to the cluster 120. Details such as power supplies, temperature and humidity control equipment, user input / output (I / O) devices for management, etc., are omitted for simplicity. Fig. One has been omitted, but it is understood that the electronic environment comprises 100 such components. Furthermore, it is understood that cluster 120 can be part of an even larger network.

[0013] The host devices 110 are designed and arranged to perform useful work. In this sense, the host devices 110 can perform certain tasks (or steps) and communicate with the cluster 120 via the connection segments 130 to jointly provide one or more advanced functions, services, and / or advancements for larger projects.

[0014] The cluster (or network) 120 is designed and arranged to transmit communication between the host devices 110. In this sense, the cluster 120 comprises leaf devices 140(a), 140(b), ... (collectively, leaf devices 140), backbone devices 150(a), 150(b), ... (collectively, backbone devices 150), and links 160 connecting the leaf devices 140 and the backbone devices 150.

[0015] The blade devices 140 are designed and arranged such that they are directly connected to the host devices 110 by means of corresponding connection segments 130. For example, the blade device 140(a) is directly connected to the host device 110(a) by one connection segment 130. Likewise, the blade device 140(b) is directly connected to the host device 110(b) by another connection segment 130, and so on.

[0016] When a leaf device 140 receives a packet from a host device 110 to be forwarded through the cluster 120, the leaf device 140 is referred to as an input leaf device 140, since it receives the packet from a packet-sending host device 110. The input leaf device 140 splits the packet into cells and sends the cells through the backbone devices 150 to finally reassemble them and deliver them to a packet-receiving host device 110.

[0017] When a leaf device 140 delivers a packet from cluster 120 to a host device 110, the leaf device 140 is referred to as the output leaf device 140, because the leaf device 140 outputs the packet to a packet-receiving host device 110. The output leaf device 140 reassembles the cells received from the backbone devices 150 to form a reassembled packet and delivers the reassembled packet to the packet-receiving host device 110.

[0018] The backbone devices 150 are designed and arranged to transfer cells between the leaf devices 140 (from input leaf devices 140 to output leaf devices 140). A suitable cell size is 512 bytes, although other cell sizes are also suitable (e.g., less than 512 bytes, 1 KB, 2 KB, etc.). Accordingly, the backbone devices 150 are capable of providing high bandwidth and low latency.

[0019] The connections 160 link the leaf devices 140 and the backbone devices 150 to each other in a fully meshed manner. Accordingly, each leaf device 140 of cluster 120 is connected to each backbone device 150 of cluster 120. In some arrangements, at least some of the connections 160 are formed directly between the switching plates that form the leaf devices 140 and the backbone devices 150 (e.g., via directly mating connectors). In some arrangements, at least some of the connections 160 are provided via additional components such as a midplane, a backplane, wiring, combinations thereof, etc.

[0020] It is understood that cluster 120 of the electronic environment 100 in Fig. Figure 1 is shown only as an example with one level of backbone devices 150. In other arrangements, the cluster 120 comprises several levels of backbone devices 150 (e.g., two levels, three levels, etc.) in which backbone devices 150 of different levels are connected via additional connections 160.

[0021] It should also be understood that cluster 120 in Fig. Figure 1 is shown, for example, with a total of eight network devices (i.e., five leaf devices 140 and three backbone devices 150). In an actual deployment, however, the Cluster 120 can have any number of leaf devices 140 (e.g., M leaf devices 140, where M is at least 2) and any number of backbone devices 150 (e.g., N backbone devices 150, where N is at least 1). In some configurations, the number of network devices in the Cluster 120 can be in the three-digit or four-digit range for compute-intensive workloads.

[0022] For example, the host devices can take the form of AI accelerators (or processing engines) that perform large sparse matrix computations distributed across hundreds or thousands of processors to reduce computation time. In some situations, the connection provided by Cluster 120 offers highly reliable, uncontested paths between the AI ​​accelerators to maximize accelerator utilization and minimize job completion time.

[0023] During operation, the host devices 110 perform processing tasks and send packets through the cluster 120 to other host devices 110. When input leaf devices 140 receive packets from packet-sending host devices 110, the input leaf devices 140 split the packets into cells and send the cells through the backbone devices 150 to output leaf devices 140. The output leaf devices 140 reassemble the cells into packets and forward the reassembled packets to packet-receiving host devices 110.

[0024] Such fragmentation and reassembly of packets can be performed in a manner that is transparent to the host devices 110. Furthermore, since the topology allows such communications to occur concurrently with limited congestion (e.g., cells are split, load is balanced in a round-robin manner, etc.), processes between the host devices 110 can be substantially optimized to utilize them as much as possible.

[0025] To ensure the smooth operation of Cluster 120, the QoS configuration 170 can be synchronized for one or more interfaces and enforced between different network devices of Cluster 120 at the start of cluster operation and / or at any time during cluster operation. In this context, it is assumed that the QoS configuration 170 is deployed on the Leaf Device 140(e) for an interface of the Leaf Device 140(e) that is connected to the Host Device 110(e). For example, the QoS configuration 170 can include a QoS policy, such as an ECN policy or a WRED policy, which is to be applied by other Leaf Devices 140 that process packets en route from the Leaf Device 140(e) to the Host Device 110(e).

[0026] After the QoS configuration 170 has been deployed to the leaf device 140(e), it is distributed from the leaf device 140(e) to the other leaf devices 140 to synchronize the QoS configuration 170 within the cluster 120. According to certain embodiments, and as will be explained in more detail shortly, such distribution of the QoS configuration 170 can be implemented using a publish / subscribe methodology.

[0027] The QoS configuration 170 for other interfaces can also be synchronized within cluster 120.

[0028] Furthermore, the QoS configuration 170 can be changed / adjusted for each (or possibly all) interfaces over time.

[0029] It is understood that the leaf devices 140 of cluster 120 can use separate operating system instances and separately deployed QoS policy settings. It should also be understood that while it may be beneficial to deploy QoS policy settings for the outbound leaf device 140, which has the interface delivering packets to the receiving host device 110, the components for enforcing the QoS policy for that interface can reside in the other leaf devices 140 of cluster 120. For example, in the context of ECN, the congestion notification bit of a packet for the receiving host would be set by the inbound leaf device 140 when the inbound leaf device 140 reaches a certain congestion level (e.g., based on the remaining buffer capacity within the inbound leaf device).Similarly, in the context of WRED, the inbound leaf device 140 would be the location where a packet is intentionally dropped to ensure network stability. Accordingly, the QoS configuration synchronization described above is a way to effectively and consistently coordinate the deployment of QoS policy settings for interfaces between leaf devices 140 of cluster 120. Further details are now provided with reference to [reference missing]. Fig. 2 explained.

[0030] Fig. Figure 2 shows another cluster 200 of network devices according to certain embodiments. Cluster 200 is similar to cluster 120 from [reference missing]. Fig. 1, since the cluster 200 has a leaf-backbone topology. In particular, the cluster 200 comprises leaf devices 140(1), 140(2) and 140(3) (collectively referred to as leaf devices 140), backbone devices 150(1) and 150(2) (collectively referred to as backbone devices 150) and connections 160 that link the leaf devices 140 and the backbone devices 150 together in a fully meshed manner.

[0031] Each sheet device 140 is equipped with several interfaces 210 (e.g., two, four, eight, 14, etc.) which are designed and arranged so that they can be connected to host devices (see also the host devices 110 in Fig. 1) For simplification and as in Fig. As shown in Figure 2, the blade device 140(1) includes an interface 210(1), the blade device 140(2) includes an interface 210(2), and the blade device 140(3) includes an interface 210(3). Although the blade devices 140 in Fig. 2 are shown with a single interface 210 for the sake of simplicity, it should be clear that the leaf devices 140, as just mentioned, can have multiple interfaces 210.

[0032] Additionally, each interface 210 of an input leaf device 140 is supported by several transmission queues 220 (e.g., two, four, eight, etc.) to hold packets destined for the various interfaces 210 of an output leaf device 140. For example, leaf devices 140(1) are operated as output leaf devices to provide packets to a host device through interface 210(3). Leaf devices 140(2) are operated as input leaf devices and include corresponding transmission queues 220(1) and 220(2) to hold packets en route to interface 210(3) of leaf device 140(3). Although leaf devices 140(1) and 140(2) are in Fig. 2 are shown for the sake of simplicity with a single transmission queue 220, it should be clear that the leaf devices 140, as just mentioned, can have multiple transmission queues 220 per interface 210.

[0033] As in Fig. As further shown in Figure 2, the QoS configuration 170 for interface 210(3) of the leaf device 140(3) was applied to the leaf device 140(3). Accordingly, the leaf device 140(3) can load the QoS configuration 170 at startup (e.g., from a configuration file). As another example, the leaf device 140(3) can receive the QoS configuration 170 while the example cluster 200 is running, for example, via a command from an operator of cluster 200. Other situations for receiving the QoS configuration 170 are also suitable.

[0034] According to certain embodiments, the QoS configuration 170 comprises a set of QoS settings (one or more QoS parameters) for imposing one or more QoS policies on packets destined for the interface 210(3) of the leaf device 140(3). In this sense, a particular QoS configuration 170 may include an identifier of an interface or interface / transmission queue pair to which the QoS configuration 170 is applied, an identifier of a particular QoS policy among several QoS policies supported by the leaf devices 140, a parameter such as a threshold that specifies when packet processing should be changed / adjusted, etc.

[0035] For example, QoS configuration 170 can specify that a latency-based ECN should be applied to packets destined for interface 210(3) when traffic exceeds a certain predefined threshold. Similarly, QoS configuration 170 can specify that a queue-based ECN should be applied to packets destined for interface 210(3) when traffic exceeds a certain predefined threshold. Finally, QoS configuration 170 can specify that default WRED should be applied to packets destined for interface 210(3) when traffic exceeds a certain predefined threshold. Other QoS policies, trigger criteria, and operational parameters, etc., are also suitable for use (e.g., drop precedence WRED, etc.).

[0036] Once QoS configuration 170 is distributed from the leaf device 140, where it was originally deployed (e.g., leaf device 140(3)), to other relevant devices within cluster 200 (leaf devices 140(1) and 140(2)), those other relevant devices can enforce the QoS policies determined (or defined) by QoS configuration 170. In some configurations, QoS configuration 170 is distributed to the other relevant devices via a publish / subscribe methodology, where agents on the other relevant devices periodically request published QoS configuration information from the owning devices. Leaf device details

[0037] Fig. Figure 3 shows a view 300 of certain details of a leaf device 140 according to certain embodiments. The leaf device 140 comprises a variety of components 310, such as a configuration agent 312, a QoS agent 314, a system database agent 316, and a connectivity agent 318. These components 310 can communicate with each other and access various other resources 330 of the leaf device (e.g., a configuration file, a system database, registers, chipsets, other circuits, etc.).

[0038] In particular, the configuration agent 312 is structured and arranged so that it can access a configuration file 332 containing configuration data such as the QoS configuration 170 for one or more interfaces 210 (see also Fig. 1 and Fig. 2) In this sense, the configuration data can be in text form (e.g., entered by a human operator). During the startup process, configuration agent 312 can read QoS configuration 170 from configuration file 332 and provide QoS configuration 170 to QoS agent 314 (e.g., in response to one or more requests from QoS agent 314), as well as read other configurations from configuration file 332 and provide this configuration data to other agents 310.

[0039] The QoS agent 314 is structured and arranged to receive the QoS configuration 170 in text-based form from the configuration agent 312, analyze and evaluate the QoS configuration 170, and present it in a more machine-readable format. Additionally, the QoS agent 314 can use this processed QoS configuration 170 to configure relevant local resources 334 (e.g., to set the status of certain circuits, thresholds, operating parameters, etc.) in order to apply one or more QoS policies defined by the QoS configuration 170. Furthermore, the QoS agent 314 can provide the processed QoS configuration 170 to the system database agent 316 for storage in a system database 336 (as a way to publish the processed QoS configuration 170).

[0040] System database agent 316 is designed and configured to store various configuration information, states, statuses, etc., for leaf device 140 in system database 336. This information can reflect different configurations / states, etc., of various cluster resources and can be retrieved by querying system database agent 316 during leaf device operation.

[0041] The connectivity agent 318 is designed and configured to access various leaf device resources 338 (e.g., memory, interfaces, etc.) to establish communication channels with other network devices 140 and to conduct communication with these other network devices 140 through these communication channels. In this sense, the connectivity agent 318 can receive a request for specific information from another local agent and then forward this request to a corresponding connectivity agent for processing via an established communication channel. Likewise, the connectivity agent 318 can receive a request for specific information via an established communication channel from a connectivity agent 318 running on another leaf device 140 and forward this request to a local agent for processing. Further details regarding such operations will be provided shortly.

[0042] As further in Fig. As shown in Figure 3, the various components 310 of the blade device 140 can be at least partially formed by electronic circuits 350, such as communication circuits, memory, and processing circuits, which are coupled to the communication circuits and the memory. The communication circuit enables the blade device 140 to communicate with external devices such as other network devices (see also Figure 3). Fig. 1 and Fig. 2) Additionally, the memory stores instructions which, when executed by the processing circuit, form a specialized circuit within the sheet device 140, such as the various components 310 described above.

[0043] In this sense, a processor can operate according to certain locally stored software constructs (e.g., an operating system, configuration information, etc.) to form a special processing circuit that enables the Blatt device 140 to exchange data with other devices via the communication circuit, enforce QoS on a per-interface basis, and so on. Such processing circuits can be implemented in various other ways, including multiple processors (or processor cores) running specialized software, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) and associated programs, discrete components, analog circuits, other hardware circuits, combinations thereof, etc.

[0044] In conjunction with one or more processors executing locally stored software, a computer program product 360 is capable of delivering all or part of the software to the electronic circuit 350. In this context, the computer program product 360 comprises a non-transient, computer-readable medium that stores a set of instructions controlling various operations of the sheet device. Examples of suitable computer-readable storage media include physical products and apparatus that store instructions in a non-volatile manner, such as DVDs, CD-ROMs, flash memory, disk storage, tape storage, and the like. Further details will now be given with reference to Fig. 4 provided.

[0045] Fig. Figure 4 shows how blade devices 140 handle the synchronization of the QoS configuration 170 according to one or more embodiments. As in Fig. As shown in Figure 4, an owner-leaf device 140(0) is the original source or originator of the QoS configuration 170. For example, the owner-leaf device 140(O) may have an interface 210 to which the QoS configuration 170 can be applied.

[0046] As further in Fig. As shown in Figure 4, the QoS configuration 170 is synchronized with a destination leaf device 140(D). For example, the destination leaf device 140(D) ​​may have one or more transmit queues for temporarily buffering packets on their way to interface 210 of the owner leaf device 140(0). Similarly, the QoS configuration 170 may be synchronized with one or more other destination leaf devices 140(D) ​​(e.g., other leaf devices 140 that have transmit queues for temporarily buffering packets on their way to interface 210 of the owner leaf device 140(0)).

[0047] At 1, the configuration agent 312 reads the QoS configuration 170 from a configuration file 332 within the owner leaf device 140(0) and provides the QoS configuration 170 (e.g. in text-structured form) to the QoS agent 314.

[0048] In step 2, the QoS agent 314 generates a processed version of the QoS configuration 170 (e.g., in a machine-readable form) and provides the processed version to the system database agent 316 for storage in the system database 336. Accordingly, the QoS configuration 170 is published for retrieval by other local agents and one or more other leaf devices 140.

[0049] In step 3, the system database agent 316, in response to a request from the connectivity agent 318, reads the processed version of the QoS configuration 170 from the system database 336 and provides the processed version of the QoS configuration 170 to the connectivity agent 318. Here, the connectivity agent 318 has requested the QoS configuration 170 from the system database agent 316 in response to a request (or query) from another connectivity agent 318 running on the target leaf device 140(D).

[0050] At point 4, the connectivity agent 318 of the owner leaf device 140(0) provides the QoS configuration 170 to the connectivity agent 318 of the target leaf device 140(D). In this context, the connectivity agents 318 establish a communication path 410 between leaf devices 140(0) and 140(D) ​​and then transmit the processed version of the QoS configuration 170 through communication path 410, thereby providing a copy of the processed version of the QoS configuration 170 to the target leaf device 140(D).

[0051] At 5, the connectivity agent 318 of the target leaf device 140(D) ​​provides the processed version of the QoS configuration 170 to the system database agent 316 of the target leaf device 140(D), and the system database agent 316 of the target leaf device 140(D) ​​stores / publishes the processed version of the QoS configuration 170 to the system database 336 of the target leaf device 140(D).

[0052] At point 6, the QoS agent 314 of the target leaf device 140(D) ​​reads the processed version of the QoS configuration 170 from the system database 336 of the target leaf device 140(D) ​​and creates the QoS configuration 170 within the target leaf device 140(D). In this sense, the QoS agent 314 configures the local QoS resources 334 of the target leaf device 140(D) ​​accordingly (e.g., it configures counters, sets one or more thresholds, allocates memory, etc.). Accordingly, the leaf devices 140(0) and 140(D) ​​have the QoS configuration 170 synchronized, and the target leaf device 140(D) ​​is able to provide the specified QoS for the interface 210 of the owner leaf device 140(0) in a suitable manner.

[0053] As in Fig. As further shown in Figure 4, a similar process can take place for other relevant leaf devices 140. That is, the processed version of the QoS configuration 170 can be similarly distributed to other target leaf devices 140(D). In this sense, the connectivity agent 318 of the owner leaf device 140(O) can establish other communication channels 410 with the other target leaf devices 140(D) ​​to transmit the processed version of the QoS configuration 170 to the other target leaf devices 140(D) ​​(see, for example, Figure 4 in Figure 4). Fig. 4) Further details will now be given with reference to the Fig. 5 and Fig. 6 provided.

[0054] Fig. 5 and Fig. Figure 6 shows procedures performed by leaf devices during QoS configuration synchronization within a cluster of network devices with a leaf backbone topology according to certain embodiments. Fig. Figure 5 shows a procedure performed by a first leaf device of the cluster. Fig. Figure 6 shows a procedure performed by another leaf device of the cluster.

[0055] With reference to Fig. 5. A procedure 500 is executed by a specialized circuit of a first leaf device to synchronize the QoS configuration between one or more other leaf devices in the cluster. Such a procedure 500 can be executed at the beginning of cluster operation (e.g., at startup) and / or at any time during cluster operation (e.g., to propagate a QoS configuration modification).

[0056] At 502, the specialized circuitry of the first leaf device locally implements the QoS configuration. In this sense, the first leaf device belongs to a plurality of leaf devices connected to a plurality of backbone devices, where the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology (see, e.g., Fig. 1 and Fig. 2).

[0057] In 504, the specialized circuitry of the first leaf device establishes communication paths between the first leaf device and other leaf devices of the plurality of leaf devices. In some arrangements, the leaf devices execute connectivity agents that are designed and arranged to establish such paths to enable control-level communication between leaf devices (see, for example, communication path 410 in Fig. 4).

[0058] In the 506 configuration, the specialized circuitry of the first leaf device provides the QoS configuration from the first leaf device to the other leaf devices through the communication channels in order to synchronize the QoS configuration with the other leaf devices of the multitude of leaf devices.

[0059] With reference to Fig. Procedure 600 is performed by a special circuit of another leaf device to synchronize the QoS configuration from the first leaf device. This procedure 600 can also be performed at the start of cluster operation and / or at any time during cluster operation.

[0060] At 602, the specialized circuitry of the other leaf device establishes a communication path with the first leaf device. At that time, the QoS configuration was already in place in the first leaf device.

[0061] With 604, the specialized circuitry of the other leaf device receives the QoS configuration from the first leaf device via the established communication path. In some configurations, and as mentioned above in conjunction with 504, a connectivity agent running on the other leaf device can send a request to a connectivity agent running on the first leaf device to read the QoS configuration once it has been published. The QoS configuration is then stored / published locally on the other leaf device (e.g., for later reading by a QoS agent running on the other leaf device).

[0062] In the 606, the specialized circuitry of the other-sheet device sets the QoS configuration locally to synchronize the QoS configuration. For example, if the QoS configuration is intended for an interface (or an interface / transmission queue pair), the specialized circuitry can impose the QoS configuration to ensure a specific quality of service is provided to the interface.

[0063] In certain embodiments, the QoS configuration received from the first leaf device can optionally be overridden. In this sense, after the QoS configuration has been established locally to synchronize it, the specialized circuitry of the other leaf device can receive an intervention to override the QoS configuration and then replace it with a different QoS configuration in response. Such an override function / feature provides flexibility, for example, by allowing the use of user-defined / local QoS configurations in specific situations (e.g., to test a new QoS configuration on specific traffic before the new QoS configuration is fully deployed). Further details

[0064] Fig. Figure 7 shows a view 700, which includes the synchronization of the QoS configuration, where an input leaf device 140(I) is the owning node in which the QoS configuration 170 is originally provided. As shown in Fig. As shown in Figure 7, the input leaf device 140(I) is capable of providing the QoS configuration 170 to one or more output leaf devices 140(E), e.g., output leaf devices 140(E)(1) and 140(E)(2), as indicated by the dashed arrows 710. In this sense, the input leaf device 140(I) is designed and arranged to receive packets from one or more packet-sending host devices, and each output leaf device 140(E) is designed and arranged to deliver the received packets to one or more destination hosts.

[0065] It should be noted that the scenario in Fig. 7 is well suited for situations where it makes sense to initially provide the QoS configuration 170 to the input leaf device 140(I), but the relevant QoS resources are available in the output leaf devices 140(E).

[0066] This scenario is similar to the one in Fig. 2, because the QoS configuration 170 starts on an owning node and is distributed to relevant non-owning nodes. In contrast to the scenario in Fig. 7 covers the scenario in Fig. 2, however, the distribution of the QoS configuration 170 from one output leaf device 140(3) to several input leaf devices 140(1), 140(2).

[0067] It should also be noted that other scenarios are suitable. In this sense, according to certain embodiments, the QoS configuration 170 is first provided to a network device that is neither an input-leaf device 140 nor an output-leaf device 140, and then the QoS configuration 170 is provided by this network device to at least one input-leaf device 140(I) and / or at least one output-leaf device 140(E) in order to synchronize the QoS configuration 170.

[0068] It should be noted that in the scenarios of Fig. 2 and Fig. 7. Each blade device 140 can provide a QoS configuration to one or more other blade devices 140 without central control. For example, in some embodiments, the QoS configuration 170 for the interfaces of all blade devices 140 is provided via a full-mesh synchronization topology, in which each blade device 140 is synchronized with every other blade device 140.

[0069] In a specific embodiment of a full-mesh synchronization topology, an output leaf device 140 containing an interface first loads the QoS configuration 170 for that interface upon startup (e.g., from a controller via the control plane). The output leaf device 140 then establishes connections to other leaf devices 140 (e.g., via connectivity agents running on the leaf devices) and makes the QoS configuration 170 for that interface available to all other leaf devices 140 through these connections (e.g., via a publish / subscribe method). The distribution of the QoS configuration for other interfaces can be performed similarly, so that the QoS configuration for all other interfaces within the cluster is now synchronized. Further details are now provided with reference to Fig. 8 provided.

[0070] Fig.Figure 8 shows a scenario 800 for QoS configuration synchronization via a central device 810 according to certain embodiments. In scenario 800, the blade device 140(e) first provides the QoS configuration 170 to the central device 810, as indicated by the dashed arrow 820. The central device 810 then provides the QoS configuration 170 to other relevant blade devices 140, as indicated by the dashed arrows 822.

[0071] In some arrangements, there are multiple central devices 810 to synchronize the QoS configuration to and from other blade devices 140. In certain embodiments, there is a primary central device 810 and a secondary central device 810 (which, for example, serves as a backup). Additionally, in some embodiments, there is a central device 810 for synchronizing the QoS configuration between one or more groups of blade devices 810, another central device 810 for synchronizing the QoS configuration between one or more other groups of blade devices 810, and so on.

[0072] In some configurations, the leaf devices 140 can communicate with each other in a similar manner to that described above for the specific full-mesh synchronization topology implementation (e.g., via connection agents implemented within the leaf devices). However, in the specific star topology implementation, the central device 810 receives the QoS configuration 170 for the interfaces from all leaf devices 140 and then distributes the QoS configuration to all other leaf devices 140.

[0073] In some arrangements, the central device 810 is part of or located within a specific blade device 140. In other arrangements, the central device 810 is part of or located within a specific backbone device 150. In still other arrangements, the central device 810 is a separate, specific apparatus that is neither a blade device 140 nor a backbone device 150 of the cluster.

[0074] In some configurations, the central device 810 is designed and arranged to perform other operations as well. For example, the central device 810 can function as a network management platform and provide a user interface 830 such as a graphical user interface (GUI) or a command-line interface (CLI) for user input / output (I / O).

[0075] In some arrangements, a specific blade device 140 or backbone device 150 operates the central device 810 for one or more interfaces, and another specific blade device 140 or backbone device 150 operates the central device 810 for one or more other interfaces.

[0076] Furthermore, it should be understood that QoS configuration synchronization can be performed for specific interfaces, but not for all interfaces. In this context, QoS configuration synchronization can be performed for a subset of Blatt devices 140 or a subset of interfaces of Blatt devices 140 (e.g., determined by another component of the solution).

[0077] For example, the cluster is operationally divided into several subnets. In this sense, another configuration could specify that there are two subnets in which leaf devices A, B, C, D never send or receive traffic from leaf devices E, F, G, H. In this situation, there is neither full QoS configuration synchronization nor a QoS configuration propagated to all participants.

[0078] As another example, the system can be dynamic, similar to "BGP rt membership," allowing dynamic signaling of which leaf device 140 (or interfaces of leaf devices 140) allow participation in a specific "partitioning" of the network. Other modifications, enhancements, situations, combinations, etc., are also suitable for use.

[0079] As described above, improved techniques aim to synchronize the QoS configuration for one or more interfaces within a cluster of 100, 200 network devices that have a backbone-leaf topology. In this sense, such a technique for a specific interface of a particular output leaf device 140 that delivers packets to a particular host device 110 might involve deploying a QoS configuration 170 for that interface within a first leaf device 140, such as the output leaf device 140, and then deploying the QoS configuration 170 from the first leaf device 140 to the other leaf devices 140 of the cluster 100, 200 to synchronize the QoS configuration 170 for that interface within the cluster 100, 200.Such techniques can be performed similarly for another interface to synchronize the QoS configuration 170 for multiple interfaces or even for all interfaces of the entire cluster 100, 200.

[0080] It should be noted that the techniques disclosed herein solve technological problems, such as providing a means for effectively coordinating the deployment of QoS policy settings for a leaf device interface among leaf devices in a backbone-leaf network. Such techniques offer technological solutions that lead to various technological efficiencies, such as the automatic propagation of the QoS configuration to relevant leaf devices after the QoS configuration has initially been deployed on an associated node, in a manner transparent to the host device; performing QoS synchronization at the start of operation and / or during operation; and so on.

[0081] Although various embodiments of the present disclosure have been shown and described in particular, it will be clear to the person skilled in the art that various changes in form and details can be made to it without departing from the spirit and scope of the present disclosure. Such modifications and improvements are intended to belong to different embodiments of the disclosure.

[0082] It should be noted that from certain perspectives, a DES (Distributed Etherlink Switch) cluster has a leaf-backbone topology, where each leaf has a fabric connection to each backbone (e.g., using the Broadcom DNX Cell Fabric system).

[0083] In some configurations, each leaf has a virtual output queue (VOQ) for each interface / transmit queue on all other leaf devices connected via the fabric. Packets are added to these VOQs and then routed through the fabric to the appropriate output leaf device to be sent over the correct interface.

[0084] This essentially corresponds to a modular system, however, each sheet runs independently and is a separate operating system instance.

[0085] In some configurations, the operating system supports a QoS policy, e.g., for ECN and / or WRED in the DES cluster. Such functionality can be implemented on each input VOQ on each leaf device, but the configuration is provided at the individual output interface.

[0086] To enable ECN and / or WRED (or other policies such as PFC or Priority Flow Control), either a symmetrical / identical configuration is required on each leaf switch, or a status release is required so that the input VOQs on each leaf device can be configured with the appropriate output interface configuration.

[0087] For ECN and WRED support, the TCP (Transmission Control Protocol) headers have an ECN bit and the packets are discarded accordingly.

[0088] Since a credit system can be used to forward packets through the fabric, an overload cannot occur on an output device.

[0089] Every second leaf device contains a VOQ for the outbound interface. Congestion occurs on the inbound leaf device (LD) if too many packets destined for an interface on a remote LD arrive at the inbound LD.

[0090] Under this overload, the operating system should apply the ECN or WRED policy configured on the outgoing LD to the VOQ on the incoming LD. This configuration is set up for a specific interface on one device, but must also be known to other devices in the cluster.

[0091] Advantageously, and in accordance with certain embodiments, an operator can configure QoS profiles on the device that has the specified interface and instruct the operating system to synchronize this configuration with all other devices that have a VOQ for it, in order to execute this configuration. This allows the automatic provisioning of all devices.

[0092] In some implementations, the QoS configuration for an interface is written on a leaf device, processed by a QoS agent, and published to a system database (e.g., sysdb). This state is read locally by one or more other platform agents for local switching. It is also read by the connectivity agent and published for incoming subscription requests via a synchronization protocol. The connectivity agent on another leaf device can then subscribe to this state and write it to the system database on that device. This state is then read by the QoS agent on the second device, ingested with the local configuration, and written to the system database.

[0093] Such a process allows a single source of truth for the QOS configuration of an interface on the device that has the interface, and other devices to automatically learn this configuration and use it when forwarding it across the structure, with the local configuration taking precedence over the synchronized configuration.

[0094] This can be implemented either as a full mesh synchronization topology (each device synchronizes with every other device) or as a star topology, where a central device synchronizes the configuration of every other device and each device then learns the configuration for all devices from the central device, with the potential for a second central device to serve as a fallback position.

[0095] One embodiment relates to a method for synchronizing the QoS configuration within a cluster of network devices with a leaf-backbone topology. The method includes: (A) Providing the QoS configuration within a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; (B) Configuring communication paths between the first blade device and other blade devices of the number of blade devices; and (C) Providing the QoS configuration from the first leaf device to the other leaf devices through the communication channels in order to synchronize the QoS configuration with the other leaf devices of the number of leaf devices.

[0096] Another embodiment relates to a device for synchronizing the QoS configuration within a cluster of network devices with a leaf-backbone topology. The device comprises a communication interface, a memory, and a processing circuit coupled to the communication interface and the memory. The memory stores instructions which, when executed by the processing circuit, cause the processing circuit to: (A) to provide the QoS configuration within a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least a part of the cluster of network devices with the leaf-backbone topology; (B) To establish communication pathways between the first leaf device and other leaf devices of the plurality of leaf devices; and (C) to provide the QoS configuration from the first leaf device through the communication channels to the other leaf devices in order to synchronize the QoS configuration with the other leaf devices of the multitude of leaf devices.

[0097] Another embodiment relates to a computer program product with a non-transitory, computer-readable medium that stores a set of instructions for synchronizing the QoS configuration within a cluster of network devices with a leaf-backbone topology. When executed by a computer-controlled circuit, the instructions cause the computer-controlled circuit to perform a procedure that includes the following: (A) Providing the QoS configuration in a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; (B) Establishing communication paths between the first leaf device and other leaf devices of the plurality of leaf devices; and (C) Providing the QoS configuration from the first leaf device to the other leaf devices through the communication channels in order to synchronize the QoS configuration with the other leaf devices of the number of leaf devices.

[0098] In some configurations, the QoS configuration includes a QoS policy for the first leaf device. Additionally, deploying the QoS configuration from the first leaf device to the other leaf devices via the communication channels includes exporting the QoS policy from the first leaf device to the other leaf devices via the communication channels so that the other leaf devices can apply the QoS policy for the first leaf device.

[0099] In some configurations, the first leaf device is coupled to a first host and configured and arranged to act as an output leaf device, delivering packets to the first host. Additionally, the other leaf devices are coupled to other hosts and configured and arranged to act as input leaf devices, receiving packets from the other hosts for delivery to the first host. The procedure further includes directing the other leaf devices to apply the QoS policy to process packets from the other hosts on their way to the first host.

[0100] In some configurations, the other leaf devices process the packets from the other hosts by splitting the packets into fabric cells and sending the fabric cells to the first leaf device via the multitude of backbone devices. Additionally, the process within the first leaf device includes reassembling the packets from the fabric cells after receiving them from the multitude of backbone devices.

[0101] In some configurations, the first leaf device is coupled to a first host and designed and arranged to operate as an input leaf device, receiving packets for delivery to other hosts. Additionally, the other leaf devices are coupled to the other hosts and designed and arranged to operate as output leaf devices, delivering packets to the other hosts. The method further includes applying the QoS policy within the first leaf device to process packets for delivery to other hosts.

[0102] In some arrangements, the procedure further includes splitting the packets for delivery to other hosts into fabric cells within the first leaf device and sending the fabric cells to the multitude of backbone devices for delivery to other hosts.

[0103] In some configurations, exporting the QoS policy from the first leaf device to the other leaf devices involves providing an Early Congestion Notification (ECN) policy as the QoS policy, which configures the other leaf devices to set congestion notification bits within packets when the cluster of network devices experiences a set of predefined high-traffic conditions.

[0104] In some configurations, the first leaf device includes an output interface coupled to a host. Additionally, the other leaf devices include queues for the first leaf device's output interface. Furthermore, the ECN policy configures the other leaf devices to set congestion message bits within packets en route to the host via the output interface, in response to the output interface queues becoming full of packets exceeding a predefined threshold.

[0105] In some configurations, exporting the QoS policy from the first leaf device to the other leaf devices involves providing a weighted random early drop policy (WRED) as the QoS policy, which configures the other leaf devices to drop packets when the cluster of network devices has a set of predefined conditions for high traffic.

[0106] In some configurations, the first leaf device includes an outbound interface coupled to a host. Additionally, the other leaf devices include queues for the outbound interface of the first leaf device. Furthermore, the WRED policy configures the other leaf devices to drop packets en route to the host through the outbound interface when the queues for the outbound interface become full with packets exceeding a predefined threshold.

[0107] In some arrangements, exporting the QoS policy from the first leaf device to the other leaf devices through the communication channels includes publishing the QoS policy on the first leaf device so that the other leaf devices can receive the QoS policy from the first leaf device through the communication channels.

[0108] In some arrangements, publishing the QoS policy on the first leaf device involves running an agent on the first leaf device to publish the QoS configuration and allow other agents running on the other leaf devices to receive the published QoS configuration.

[0109] In some arrangements, establishing communication pathways between the first leaf device and other leaf devices of the multitude of leaf devices involves forming connections directly between the first leaf device and the other leaf devices to allow the connectivity agents running on the other leaf devices to read the published QoS configuration directly from the first leaf device.

[0110] In some configurations, establishing communication pathways between the first-leaf device and other leaf devices within a plurality of leaf devices involves creating a connection between the first-leaf device and a central device. This allows the central device to read the published QoS configuration from the first-leaf device and the other leaf devices to read the published QoS configuration from the central device. In some configurations, the first-leaf device includes multiple interfaces with multiple transmission queues. Additionally, the QoS policy is applied to a specific interface / transmission queue pair of the first-leaf device.Furthermore, the QoS configuration is provided within the first leaf device by loading the QoS policy during a startup process before the first leaf device enters normal operating mode, applying the QoS policy to the specific interface / transmit queue pair of the first leaf device.

[0111] In some arrangements, the procedure further includes loading another QoS policy during the startup process before the first leaf device enters normal operating mode, with the additional QoS policy being applied to another interface / send queue pair of the first leaf device.

[0112] Another embodiment comprises a method for synchronizing the QoS configuration within a cluster of network devices with a leaf-backbone topology. The method includes: (A) Establishing a communication path with a first leaf device from a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least a part of the cluster of network devices with the leaf-backbone topology; (B) Receiving the QoS configuration from the first leaf device through the established communication path; and (C) Create the QoS configuration locally to synchronize the QoS configuration.

[0113] Another embodiment relates to a device for synchronizing the QoS configuration within a cluster of network devices with a leaf-backbone topology. The device comprises a communication interface, a memory, and a processing circuit that is coupled to the communication interface and the memory. The memory stores instructions which, when executed by the processing circuit, cause the processing circuit to: (A) to establish a communication path with a first leaf device from a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; (B) to obtain the QoS configuration through the established communication path from the first leaf device; and (C) to apply the QoS configuration locally in order to synchronize the QoS configuration.

[0114] Another embodiment relates to a computer program product with a non-transitory, computer-readable medium on which a set of instructions is stored for synchronizing the QoS configuration within a cluster of network devices with a leaf-backbone topology. When executed by a computer-controlled circuit, the set of instructions causes the computer-controlled circuit to perform a procedure of: (A) Establishing a communication path with a first leaf device from a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; (B) Receiving the QoS configuration from the first leaf device through the established communication path; and (C) Create the QoS configuration locally to synchronize the QoS configuration.

[0115] In some configurations, the QoS configuration includes a QoS policy for the first leaf device. Additionally, receiving the QoS configuration from the first leaf device through the established communication channel includes reading the QoS policy after the first leaf device has published the QoS policy.

[0116] In some arrangements, the procedure further includes, after the QoS configuration has been applied locally to synchronize the QoS configuration, receiving an override command to override the QoS configuration and replacing the QoS configuration with a different QoS configuration in response to the override command.

[0117] Experts will therefore understand that various changes in form and detail can be made to the embodiments disclosed herein without deviating from the scope of the following claims.

Claims

[1] Computer program product comprising a non-transitory, computer-readable medium that stores a set of instructions for synchronizing the quality of service (QoS) configuration within a cluster of network devices with a leaf-backbone topology; wherein the set of instructions, when executed by a computer-controlled circuit, causes the computer-controlled circuit to: to provide the QoS configuration within a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; to establish communication pathways between the first leaf device and other leaf devices of the number of leaf devices; and to provide the QoS configuration from the first leaf device through the communication channels to the other leaf devices in order to synchronize the QoS configuration with the other leaf devices of the number of leaf devices. [2] Computer program product according to claim 1, wherein the QoS configuration comprises a QoS policy for the first blade device; and wherein the computer-controlled circuit, when providing the QoS configuration from the first blade device through the communication paths to the other blade devices, is designed and arranged to: to export the QoS policy from the first leaf device to the other leaf devices via the communication channels, so that the other leaf devices can apply the QoS policy for the first leaf device. [3] Computer program product according to claim 2, wherein the first leaf device is coupled to a first host and is constructed and arranged such that it is operated as an output leaf device that provides packets to the first host; wherein the other leaf devices are coupled to other hosts and are designed and arranged to operate as input leaf devices, receiving packets from the other hosts in order to deliver them to the first host; and wherein the set of instructions, when executed by the computer-controlled circuit, further causes the computer-controlled circuit to: instruct the other leaf devices to apply the QoS policy to process packets from the other hosts on the way to the first host. [4] Computer program product according to claim 3, wherein the other leaf devices process the packets from the other hosts by dividing the packets into fabric cells and sending the fabric cells to the first leaf device via the plurality of backbone devices; and wherein the set of instructions, when executed by the computer-controlled circuit, further causes the computer-controlled circuit to: within the first sheet device, the packages from the fabric cells are reassembled after being received from the multitude of backbone devices. [5] Computer program product according to claim 2, wherein the first leaf device is coupled to a first host and is designed and arranged to be operated as an input leaf device that receives packets for delivery to other hosts; wherein the other leaf devices are coupled to the other hosts and are designed and arranged to operate as output leaf devices delivering packets to the other hosts; and wherein the set of instructions, when executed by the computer-controlled circuit, further causes the computer-controlled circuit to: to apply the QoS policy within the first leaf device to process packets for delivery to other hosts. [6] Computer program product according to claim 5, wherein the set of instructions, when executed by the computer-controlled circuit, further causes the computer-controlled circuit to: within the first leaf device, the packets for delivery to other hosts are divided into fabric cells, and the fabric cells are sent to the multitude of backbone devices for delivery to other hosts. [7] Computer program product according to claim 2, wherein the computer-controlled circuit is set up and arranged during the export of the QoS policy from the first leaf device to the other leaf devices in order to: to provide an Early Congestion Notification (ECN) policy as a QoS policy, which configures the other leaf devices to set congestion notification bits within packets when the cluster of network devices experiences a set of predefined high traffic conditions. [8] Computer program product according to claim 7, wherein the first output sheet device comprises an output interface coupled to a host; and wherein the other output leaf devices include queues for the output interface of the first output leaf device; and where the ECN policy configures the other outbound leaf devices to set the congestion notification bits in packets that are on their way to the host via the outbound interface, in response to the outbound interface queues being filled with packets beyond a predefined capacity threshold. [9] Computer program product according to claim 2, wherein the computer-controlled circuit is set up and arranged during the export of the QoS policy from the first leaf device to the other leaf devices in order to: to provide a Weighted Random Early Discard (WRED) policy as a QoS policy, which configures the other leaf devices to discard packets when the cluster of network devices has a set of predefined high traffic conditions. [10] Computer program product according to claim 9, wherein the first sheet device comprises an output interface coupled to a host; and wherein the other leaf devices include queues for the output interface of the first leaf device; and The WRED policy configures the other leaf devices to discard packets en route to the host via the outbound interface when the outbound interface queues are filled with packets beyond a predefined capacity threshold. [11] Computer program product according to claim 2, wherein the computer-controlled circuit, when exporting the QoS policy from the first leaf device to the other leaf devices through the communication paths, is constructed and arranged to: to publish the QoS policy on the first leaf device so that the other leaf devices can receive the QoS policy from the first leaf device through the communication channels. [12] Computer program product according to claim 11, wherein the computer-based circuit, when publishing the QoS policy on the first sheet device, is set up and arranged to: to run an agent on the first leaf device to publish the QoS configuration and allow other agents running on the other leaf devices to receive the published QoS configuration. [13] Computer program product according to claim 12, wherein the computer-based circuit, when establishing the communication paths between the first blade device and other blade devices of the plurality of blade devices, is constructed and arranged to: to establish connections directly between the first leaf device and the other leaf devices, in order to allow the connectivity agents running on the other leaf devices to read the published QoS configuration directly from the first leaf device. [14] Computer program product according to claim 12, wherein the computer-controlled circuit, when establishing the communication paths between the first blade device and other blade devices of the plurality of blade devices, is constructed and arranged to: to form a connection between the first leaf device and a central device to allow the central device to read the published QoS configuration from the first leaf device, and the other leaf devices to read the published QoS configuration from the central device. [15] Computer program product according to claim 2, wherein the first sheet device comprises multiple interfaces having multiple transmission queues; where the QoS policy is applied to a specific interface / transmission queue pair of the first-leaf device; and the computer-controlled circuit is set up and arranged within the first blade device when providing the QoS configuration in order to: to load the QoS policy during a startup process before the first leaf device enters normal operating mode, with the QoS policy applying to the specific interface / transmit queue pair of the first leaf device. [16] Computer program product according to claim 15, wherein the set of instructions, when executed by the computer-controlled circuit, further causes the computer-controlled circuit to: to load a different QoS policy during the startup process before the first leaf device enters normal operating mode, with the other QoS policy being applied to a different interface / transmit queue pair of the first leaf device. [17] Network apparatus for synchronizing the quality of service (QoS) configuration within a cluster of network devices having a backbone-leaf topology, wherein the network apparatus comprises: a processing circuit; and a memory containing program code which, when executed by the processing circuit, causes the processing circuit to: to provide the QoS configuration in a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; to establish communication pathways between the first leaf device and other leaf devices of the number of leaf devices; and to provide the QoS configuration from the first leaf device through the communication channels to the other leaf devices in order to synchronize the QoS configuration with the other leaf devices of the number of leaf devices. [18] Network apparatus according to claim 17, wherein the QoS configuration comprises a QoS policy for the first blade device; and wherein the processing circuit, when providing the QoS configuration from the first blade device through the communication paths to the other blade devices, is constructed and arranged to: to export the QoS policy from the first leaf device to the other leaf devices via the communication channels, in order to enable the other leaf devices to apply the QoS policy for the first leaf device. [19] Network apparatus according to claim 18, wherein the first leaf device is coupled to a first host and is set up and arranged to be operated as an output leaf device that delivers packets to the first host; wherein the other leaf devices are coupled to other hosts and are designed and arranged to operate as input leaf devices, receiving packets from the other hosts to deliver them to the first host; and where, when executed by the processing circuit, the program code further causes the processing circuit to: to instruct the other leaf devices to apply the QoS policy to process packets from the other hosts on their way to the first host. [20] Network apparatus according to claim 19, wherein the other leaf devices process the packets from the other hosts by dividing the packets into fabric cells and sending the fabric cells through the plurality of backbone devices to the first leaf device; and where, when executed by the processing circuit, the program code further causes the processing circuit to: within the first sheet device, the packages from the fabric cells are reassembled after being received from the multitude of backbone devices. [21] Network apparatus according to claim 18, wherein the first leaf device is coupled to a first host and is designed and arranged to be operated as an input leaf device that receives packets for delivery to other hosts; wherein the other leaf devices are coupled to the other hosts and are designed and arranged to operate as output leaf devices, providing packets to the other hosts; and wherein the program code, when executed by the processing circuit, further causes the processing circuit to: to apply the QoS policy within the first leaf device to process packets for delivery to other hosts. [22] Network apparatus according to claim 21, wherein the program code, when executed by the processing circuit, further causes the processing circuit to: within the first leaf device, the packets are divided into fabric cells for delivery to other hosts, and the fabric cells are sent to the multitude of backbone devices for delivery to other hosts. [23] Network apparatus according to claim 18, wherein the processing circuit is set up and arranged during the export of the QoS policy from the first sheet device to the other sheet devices in order to: As a QoS policy, provide an Early Congestion Notification (ECN) policy that configures the other leaf devices to set congestion notification bits within packets when the cluster of network devices experiences a set of predefined high traffic conditions. [24] Network apparatus according to claim 23, wherein the first leaf device comprises an output interface coupled to a host; and wherein the other leaf devices include queues for the output interface of the first leaf device; and The ECN policy configures the other leaf devices to set the congestion notification bits within packets that are on their way to the host through the outbound interface, in response to the outbound interface queues being filled with packets above a predefined threshold. [25] Network apparatus according to claim 18, wherein the processing circuit is set up and arranged during the export of the QoS policy from the first sheet device to the other sheet devices in order to: to provide a Weighted Random Early Discard (WRED) policy as a QoS policy, which configures the other leaf devices to discard packets when the cluster of network devices experiences a set of predefined high traffic conditions. [26] Network apparatus according to claim 25, wherein the first leaf device comprises an output interface coupled to a host; and wherein the other leaf devices include queues for the output interface of the first leaf device; and The WRED policy configures the other leaf devices to discard packets en route to the host via the outbound interface when the outbound interface queues are filled with packets beyond a predefined capacity threshold. [27] Network apparatus according to claim 18, wherein the processing circuit, when exporting the QoS policy from the first leaf device through the communication paths to the other leaf devices, is set up and arranged to: to publish the QoS policy on the first leaf device so that the other leaf devices can receive the QoS policy from the first leaf device through the communication channels. [28] Network apparatus according to claim 27, wherein the processing circuit, when it publishes the QoS policy on the first sheet device, is set up and arranged to: to run an agent on the first leaf device to publish the QoS configuration and allow other agents running on the other leaf devices to receive the published QoS configuration. [29] Network apparatus according to claim 28, wherein the processing circuit is set up and arranged when establishing the communication paths between the first blade device and other blade devices of the plurality of blade devices in order to: to establish connections directly between the first leaf device and the other leaf devices in order to allow the connectivity agents running on the other leaf devices to read the published QoS configuration directly from the first leaf device. [30] Network apparatus according to claim 28, wherein the processing circuit is set up and arranged in order to: when establishing the communication paths between the first blade device and other blade devices of the plurality of blade devices. to establish a connection between the first leaf device and a central device to enable the central device to read the published QoS configuration from the first leaf device, and to enable the other leaf devices to read the published QoS configuration from the central device. [31] Network apparatus according to claim 18, wherein the first leaf device comprises multiple interfaces with multiple transmission queues; where the QoS policy is applied to a specific interface / send queue pair of the first leaf device; and the processing circuitry is set up and arranged within the first blade device when providing the QoS configuration in order to: to load the QoS policy during a startup process before the first leaf device enters normal operating mode, with the QoS policy applying to the specific interface / send queue pair of the first leaf device. [32] Network apparatus according to claim 31, wherein the program code, when executed by the processing circuit, further causes the processing circuit to: to load another QoS policy during the startup process before the first leaf device enters normal operating mode, with the additional QoS policy being applied to another interface / transmit queue pair of the first leaf device. [33] Computer program product comprising a non-transitory, computer-readable medium that stores a set of instructions for synchronizing the quality of service (QoS) configuration within a cluster of network devices with a leaf-backbone topology; wherein the set of instructions, when executed by a computer-controlled circuit, causes the computer-controlled circuit to: to establish a communication path with a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; to obtain the QoS configuration through the established communication path from the first leaf device; and to create the QoS configuration locally in order to synchronize the QoS configuration. [34] Computer program product according to claim 33, wherein the QoS configuration comprises a QoS policy for the first blade device; and wherein the computer-controlled circuit, when it receives the QoS configuration through the established communication path from the first blade device, is set up and arranged as follows: Read the QoS policy after the first leaf device has published the QoS policy. [35] Computer program product according to claim 34, wherein the set of instructions, when executed by the computer-controlled circuit, further causes the computer-controlled circuit to: After the QoS configuration has been applied locally to synchronize the QoS configuration, an intervention is received to overwrite the QoS configuration; and the QoS configuration is replaced with a different QoS configuration in response to the intervention. [36] Network apparatus for synchronizing a quality of service (QoS) configuration within a cluster of network devices having a leaf-backbone topology, wherein the network apparatus comprises: a processing circuit; and a memory in which program code is stored which, when executed by the processing circuit, causes the processing circuit to: to establish a communication path with a first leaf device of a plurality of leaf devices coupled to a plurality of backbone devices, wherein the plurality of leaf devices and the plurality of backbone devices form at least one section of the cluster of network devices with the leaf-backbone topology; The QoS configuration is obtained through the established communication path from the first leaf device; and Create the QoS configuration locally in order to synchronize the QoS configuration. [37] Network apparatus according to claim 36, wherein the QoS configuration comprises a QoS policy for the first leaf device; and wherein the processing circuit, when it receives the QoS configuration through the established communication path from the first leaf device, is set up and arranged as follows: Read the QoS policy after the first leaf device has published the QoS policy. [38] Network apparatus according to claim 37, wherein the program code, when executed by the processing circuit, further causes the processing circuit to: After the QoS configuration has been applied locally to synchronize the QoS configuration, an intervention is received to overwrite the QoS configuration; and the QoS configuration is replaced with a different QoS configuration in response to the intervention.

Images