A multi-level flow scheduling and shaping method and system

Abstract

This invention relates to the field of traffic scheduling and shaping technology, and in particular to a multi-level traffic scheduling and shaping method and system. It is applied to a multi-level traffic scheduling and shaping architecture. This architecture comprises a three-level scheduling structure consisting of a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer. In this method: the port scheduling layer allocates total bandwidth authorization tokens to each port according to a weighted round-robin weight and then rate-limits them via a port shaper; the authorization tokens obtained by the ports are allocated to each traffic category by the traffic category scheduling layer, where they are rate-limited by a committed rate shaper and an additional rate shaper, respectively. Each traffic category consumes committed authorization tokens first, and then consumes additional authorization tokens after that; finally, the priority scheduling layer allocates them to each priority level, forming token buckets uniquely identified by triples. When a data stream arrives, the target token bucket is located based on the triple, and authorization token determination is performed. This invention achieves decoupled configuration and elastic bandwidth management for multi-granularity traffic management, scheduling, and shaping.

Description

Technical Field

[0001] This invention relates to the field of traffic scheduling and shaping technology, and in particular to a multi-level traffic scheduling and shaping method and system. Background Technology

[0002] Enhanced Transmission Selection (ETS) is a Transmission Selection Algorithm (TSA) specified in the IEEE 802.1Qaz standard and is a component of the IEEE 802.1 Data Center Bridging (DCB) interface architecture. ETS aims to enhance the transmission selection mechanism to support bandwidth allocation across multiple traffic classes.

[0003] ETS functionality is typically implemented on the network interface card (NIC) chip, used to manage bandwidth allocation and traffic control across multiple ports and service categories. Within the NIC chip, the ETS processes data streams from different queues and allocates appropriate egress bandwidth based on their priority and service type to ensure differentiated quality of service (QoS) guarantees for different types of data streams.

[0004] In traditional ETS schemes, scheduling and shaping functions only apply to priority levels within a port. Specifically, the eight priority levels within the same port are scheduled using either weighted round-robin or strict priority. However, the aforementioned traditional ETS scheme has the following shortcomings:

[0005] First, the scheduling hierarchy is too simple to meet the needs of multi-granularity traffic management. Traditional ETS only performs scheduling at the priority level within a port, lacking a coarse-grained allocation layer above the port and a fine-grained custom packet layer below the priority level. With the increasing diversity of network services, the bandwidth requirements of different ports and different service types on the same port vary significantly. A single-level scheduling cannot implement differentiated traffic control strategies at different granularities. Furthermore, the token bucket of traditional ETS is usually only associated with priority. Data flows from different ports or different services but with the same priority share the same token bucket, making it impossible to independently control traffic and manage authorization tokens, resulting in insufficient precision in traffic scheduling.

[0006] Second, the coupling of shaping and scheduling functions limits configuration flexibility. In traditional ETS systems, shaping and scheduling functions are bound at the same level. The shaper is an auxiliary module of the scheduler rather than an independent unit, making it impossible to configure shaping parameters independently at different levels. When it's necessary to perform rate limiting at the port level while simultaneously requiring independent rate control for different types of services at the service level, traditional ETS cannot meet both requirements simultaneously. This coupling between shaping and scheduling limits the scope of traffic management policy adjustments, making it difficult to adapt to complex and ever-changing business scenarios. Summary of the Invention

[0007] To address one of the aforementioned technical problems, the present invention adopts the following technical solution:

[0008] According to one aspect of the present invention, a multi-level traffic scheduling and shaping method is provided. The method is applied to a multi-level traffic scheduling and shaping architecture, which includes a three-level scheduling structure consisting of a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer. Each scheduling layer is used to perform the allocation of authorization tokens at the corresponding level.

[0009] The system comprises the following layers: a port scheduling layer for distributing authorization tokens between ports, with each port equipped with a port shaper to independently limit the authorization token issuance rate; a traffic category scheduling layer for distributing authorization tokens between traffic categories under each port, with each traffic category equipped with a committed rate shaper and an additional rate shaper; a committed rate shaper for limiting the committed authorization token issuance rate for each traffic category, and an additional rate shaper for limiting the additional authorization token issuance rate for each traffic category; and a priority scheduling layer for distributing authorization tokens between priorities under each traffic category. The shapers and scheduling layers at each corresponding level are independently configured modules, with each shaper independently outputting control signals to limit the upper limit of authorization token issuance at its corresponding level.

[0010] The methods include:

[0011] The port scheduling layer distributes the total bandwidth authorization tokens to each port according to the weighted round-robin weight of each port; the port shaper limits the upper limit of authorization tokens issued to each port according to the shaping parameters of the corresponding port.

[0012] The authorization tokens obtained by each port are allocated to each traffic category by the traffic category scheduling layer according to the scheduling configuration of each traffic category; the committed rate shaper limits the upper limit of committed authorization tokens according to the committed rate of each traffic category, and the extra rate shaper limits the upper limit of extra authorization tokens according to the extra rate of each traffic category. Each traffic category consumes committed authorization tokens first, and consumes extra authorization tokens after the committed authorization tokens are used up.

[0013] The authorization tokens obtained by each traffic category are distributed to each priority according to the scheduling configuration of each priority by the priority scheduling layer, forming tokens in each token bucket; each token bucket is uniquely identified by a port identifier, a traffic category identifier, and a priority identifier.

[0014] When a data stream arrives, the target token bucket is located based on the port identifier, traffic category identifier, and priority identifier corresponding to the data stream, and the authorization token is determined for the data stream based on the current number of tokens in the target token bucket.

[0015] According to another aspect of the present invention, a multi-level traffic scheduling and shaping system is provided, comprising:

[0016] The architecture configuration module is used to configure the multi-level traffic scheduling and shaping architecture. The multi-level traffic scheduling and shaping architecture includes a three-level scheduling structure consisting of a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer. Each scheduling layer is used to execute the allocation of authorization tokens at the corresponding level.

[0017] The system comprises the following layers: a port scheduling layer for distributing authorization tokens between ports, with each port equipped with a port shaper to independently limit the authorization token issuance rate; a traffic category scheduling layer for distributing authorization tokens between traffic categories under each port, with each traffic category equipped with a committed rate shaper and an additional rate shaper; a committed rate shaper for limiting the committed authorization token issuance rate for each traffic category, and an additional rate shaper for limiting the additional authorization token issuance rate for each traffic category; and a priority scheduling layer for distributing authorization tokens between priorities under each traffic category. The shapers and scheduling layers at each corresponding level are independently configured modules, with each shaper independently outputting control signals to limit the upper limit of authorization token issuance at its corresponding level.

[0018] The port scheduling module is used to distribute the total bandwidth authorization token to each port according to the weighted round-robin weight of each port through the port scheduling layer, and to limit the upper limit of authorization token issuance for each port according to the shaping parameters of the corresponding port through the port shaper.

[0019] The traffic category scheduling module is used to allocate the authorization tokens obtained by each port to each traffic category according to the scheduling configuration of each traffic category through the traffic category scheduling layer, and limit the upper limit of the promised authorization tokens according to the promised rate of each traffic category through the promised rate shaper, and limit the upper limit of the additional authorization tokens according to the additional rate of each traffic category through the additional rate shaper. Each traffic category consumes the promised authorization tokens first, and consumes the additional authorization tokens after the promised authorization tokens are used up.

[0020] The priority scheduling module is used to allocate the authorization tokens obtained by each traffic category to each priority according to the scheduling configuration of each priority through the priority scheduling layer, forming tokens in each token bucket. Each token bucket is uniquely identified by port identifier, traffic category identifier and priority identifier.

[0021] The data stream processing module is used to locate the target token bucket based on the port identifier, traffic category identifier, and priority identifier corresponding to the data stream when it arrives, and to determine the authorization token for the data stream based on the current number of tokens in the target token bucket.

[0022] This invention has at least one of the following beneficial effects:

[0023] By establishing a three-level scheduling structure and configuring independent scheduling algorithms at each level, the problems of single scheduling levels and coarse token bucket management in traditional ETS are solved. As in this invention, a three-level scheduling structure consisting of a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer is configured. Each scheduling layer is used to execute the allocation of authorized tokens at its corresponding level. Since each scheduling layer can be independently configured with different scheduling algorithms (the port scheduling layer configures weighted round-robin weights, the traffic category scheduling layer configures the association between each traffic category and priority and the scheduling algorithm, and the priority scheduling layer configures strict priority scheduling, round-robin scheduling, or weighted fair queue scheduling and the corresponding weight ratios), the total bandwidth authorized tokens are allocated sequentially through the three scheduling layers, forming token buckets uniquely identified by a triplet of port identifier, traffic category identifier, and priority identifier. Based on the above three-level scheduling structure and the independently configurable scheduling algorithms at each level, differentiated traffic control strategies can be implemented at three granularities: port level, traffic category level, and priority level, thereby meeting the needs of multi-granularity traffic management. Meanwhile, based on the characteristic that each token bucket is uniquely identified by a triplet, data streams from different ports and different traffic categories have their own independent token buckets, and the tokens they authorize do not interfere with each other, thus overcoming the management problems caused by the traditional ETS single-level scheduling and shared token bucket.

[0024] By setting the shapers and scheduling layers at each level as independently configured modules, the problem of coupling between the shaping and scheduling functions and limited configuration flexibility in traditional ETS is solved. For example, in this invention, the port shaper and port scheduling layer are independently configured modules, as are the traffic category shaper and traffic category scheduling layer. Each shaper independently outputs control signals to limit the upper limit of authorization token issuance at its corresponding level. Because the shaping and scheduling functions are decoupled into independent modules at each level and each shaper independently outputs control signals, adjusting the shaper's parameters does not affect the scheduler's algorithm execution, and adjusting the scheduler's algorithm or weights does not affect the shaper's rate limiting control. Therefore, users can independently adjust the parameters of any shaper without changing the scheduling configuration, and can also independently adjust the algorithm or weights of any scheduling layer without changing the shaping configuration. This achieves orthogonal configuration of the scheduling and shaping strategies, thereby significantly improving the flexibility and customizability of traffic management strategies.

[0025] Elastic bandwidth management is achieved by combining a traffic category-level committed rate shaper with an additional rate shaper. As described in this invention, each traffic category is configured with a traffic category shaper, which includes a committed rate shaper and an additional rate shaper. The committed rate shaper limits the upper limit of committed authorization tokens according to the committed rate of each traffic category, while the additional rate shaper limits the upper limit of additional authorization tokens according to the additional rate of each traffic category. Each traffic category consumes committed authorization tokens first, and then consumes additional authorization tokens after the committed authorization tokens are exhausted. Based on the independent configuration of the committed rate shaper and the additional rate shaper, and the consumption order of prioritizing the consumption of committed authorization tokens and then using additional authorization tokens, each traffic category first obtains the bandwidth guarantee of the committed rate, and can continue to consume additional authorization tokens to cope with sudden traffic surges after its committed authorization tokens are exhausted. At the same time, since the upper limit of additional authorization tokens is independently controlled by the additional rate shaper, when a traffic category does not need to use additional bandwidth, its remaining additional authorization tokens can be used by other traffic categories. Through the above mechanism, each service type can obtain a minimum bandwidth guarantee and can flexibly borrow additional bandwidth when other services have idle bandwidth, thereby improving the overall bandwidth utilization rate. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the link architecture for a multi-level traffic scheduling and shaping method provided in an embodiment of the present invention.

[0028] Figure 2 This is a schematic diagram of a multi-level traffic scheduling and shaping architecture provided in an embodiment of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] As a first possible embodiment of the present invention, such as Figure 1 As shown, a multi-level traffic scheduling and shaping method is provided, applied to a multi-level traffic scheduling and shaping architecture. The multi-level traffic scheduling and shaping architecture comprises a three-level scheduling structure consisting of a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer. Each scheduling layer is responsible for executing the allocation of authorization tokens at its corresponding level. Each scheduling layer implements its scheduling function through a corresponding credit scheduler.

[0031] The port scheduling layer is used to perform authorization token allocation between ports. Figure 2 The chip-level credit scheduler is used. Each port is configured with a port shaper to independently rate-limit the issuance rate of authorization tokens for each port. The port shaper is a port-level committed rate shaper. See attached... Figure 2 As shown, the chip-level credit scheduler and the port shaper are independently configured modules. The port shaper independently outputs rate-limiting control signals to constrain the authorization token issuance rate of the chip-level credit scheduler. The port shaper only configures the committed rate (i.e., bucket C) and does not involve the additional rate (bucket E). The reason for this setting is that the port level only needs to limit the total outbound bandwidth and does not need to distinguish between committed bandwidth and additional bandwidth.

[0032] The traffic category scheduling layer is used to perform authorization token allocation between different traffic categories under each port. The traffic category scheduling layer is... Figure 2 The port-level credit scheduler. Each traffic category is configured with a committed rate shaper and an additional rate shaper; the committed rate shaper is the additional... Figure 2 The traffic category commitment rate shaper is used to rate-limit the issuance rate of commitment authorization tokens for each traffic category (corresponding to bucket C); additional rate shapers are attached. Figure 2 The traffic category additional rate shaper is used to rate-limit the issuance rate of additional authorization tokens for each traffic category (corresponding to the E-bucket). See attached... Figure 2As shown, the port-level credit scheduler, traffic category committed rate shaper, and traffic category additional rate shaper are independently configured modules. The two shapers independently output control signals to constrain the issuance rates of committed authorization tokens and additional authorization tokens, respectively. The reason for setting up two independent shapers at the traffic category level—the committed rate shaper (C bucket) and the additional rate shaper (E bucket)—is that the committed rate corresponds to the basic bandwidth guarantee of the service and should be prioritized and independently rate-limited; the additional rate corresponds to bursty or elastic bandwidth demands and is only used after the basic bandwidth demand is met. Independent configuration of both allows for a balance between bandwidth guarantee and elastic expansion.

[0033] The priority scheduling layer is used to perform authorization token allocation among different priorities under each traffic category. The priority scheduling layer is... Figure 2 Traffic category credit scheduler.

[0034] The shapers at each level are independent modules from the scheduling layer at that level. Each shaper independently outputs control signals to limit the upper limit of the authorization tokens issued at the corresponding level.

[0035] Appendix Figure 2 In the token bucket configuration, `crdt / tc_crs` are traffic category credit registers, storing the current token quantity for each traffic category's token bucket; `credit / pri_crs` are priority credit registers, storing the current token quantity for each priority's token bucket. The credit status register summarizes the current status information of each level of token bucket (including the current token quantity, whether it's in a token shortage state, etc.) and provides this status information to the data stream processing module for authorization token determination. It also feeds back the status information to each level of the scheduling layer to assist in scheduling decisions. The arrow between the traffic category credit register and the priority credit register indicates the direction of token bucket status propagation—the status of the upper-level token bucket affects the authorization token allocation of the lower-level token bucket. `ets_slot` is the time slot controller, generating periodic pulse signals to drive each level of the scheduling layer to execute authorization token allocation according to a unified clock cycle. `dec` is the decoder, used to decode configuration parameters and feedback signals; `status` is the status register, storing the current status information of each module. `fc` is the status feedback controller.

[0036] Furthermore, the multi-level traffic scheduling and shaping architecture also includes a user configuration channel, used to receive user-configured scheduling and shaping parameters and distribute them to each level of scheduling layer and each level of shaper. The user configuration channel is independent of the data stream transmission channel. Specifically, the port scheduling layer supports configuring the weighted round-robin weights for each port. The traffic category scheduling layer supports configuring the association between each traffic category and priority, as well as configuring round-robin scheduling or weighted fair queue scheduling. The priority scheduling layer supports configuring strict priority scheduling, round-robin scheduling, or weighted fair queue scheduling; when configured as weighted fair queue scheduling, it also supports configuring the weight ratio of each priority level. The user configuration channel is attached... Figure 2 The user configuration interface (USER) in the system.

[0037] Based on the aforementioned three-level scheduling structure (port scheduling layer, traffic category scheduling layer, and priority scheduling layer), authorization tokens are allocated sequentially from the starting point of the chip's total bandwidth through the port level, traffic category level, and priority level, ultimately reaching each token bucket uniquely identified by a triplet. Traditional ETS solutions only perform single-level scheduling at the priority level within a port, lacking fine-grained control above the port level and below the priority level. In contrast, this invention implements differentiated traffic control at three different granularities through a three-level scheduling structure: the port scheduling layer controls the bandwidth allocation ratio among ports, solving the problem of "how to allocate the chip's total bandwidth among multiple ports"; the traffic category scheduling layer controls the bandwidth allocation among different service types under each port, solving the problem of "how different types of services share bandwidth under the same port"; and the priority scheduling layer controls the bandwidth allocation among different service levels under the same service type, solving the problem of "how to provide differentiated services for different priorities within the same service". The three scheduling layers are configured independently and work collaboratively, fully covering the multi-granularity traffic management needs from the chip level to the flow level, overcoming the limitations of the traditional ETS's single-level scheduling.

[0038] The method includes the following steps.

[0039] Step 101: The port scheduling layer distributes the total bandwidth authorization tokens to each port according to the weighted round-robin weights of each port. The port shaper limits the upper limit of authorization tokens issued to each port according to the shaping parameters of the corresponding port.

[0040] like Figure 1 As shown, the chip node represents the starting point of the total bandwidth authorization token (chip level), and port0 to port14 represent the individual port nodes. The WRR annotation between the chip node and each port node indicates that the chip level performs authorization token allocation to each port according to a weighted round-robin scheduling strategy. The connection between each port node and the tc node is marked with a port shaper symbol, indicating that each port must undergo rate limiting control by the port shaper before issuing the authorization token to the traffic category.

[0041] Specifically, the port scheduling layer uses the weighted round-robin weight values ​​of each port. Determine the authorization token allocation ratio for each port. , The following conditions must be met:

[0042]

[0043] Where N is the total number of ports. The weighted round-robin weight value for the i-th port. Let be the weighted round-robin weight value for the j-th port, where i and j are both port indices. The port scheduling layer allocates weights according to the authorization token allocation ratio. Distribute the total bandwidth authorization token to each port.

[0044] Authorization tokens are credentials for data transmission, with each token corresponding to the right to send a unit of data. The port scheduling layer, as the top layer in the three-level scheduling structure, is responsible for the initial allocation of all authorization tokens corresponding to the chip's total bandwidth among the ports. The Weighted Round Robin (WRR) scheduling algorithm achieves differentiated control of the bandwidth allocation ratio for each port by configuring different weight values ​​for each port.

[0045] The port shaper is designed to prevent packet loss caused by excessive traffic bursts from high-speed ports onto low-speed links, as different ports may connect to network links with varying speeds or receiving devices with different performance. Since the port shaper and port scheduling layer are independent modules, users can independently adjust the shaping parameters of any port without modifying the port scheduling layer's weight configuration, thus achieving decoupled control between bandwidth allocation ratios and port rate limits.

[0046] Based on the aforementioned architecture where the port scheduling layer and port shaper are independently configured, the scheduling layer focuses on the logical decision of "allocating bandwidth according to weight ratios," while the shaper independently executes the physical constraint of "limiting rates according to the port rate cap." When the link rate of a port changes or the rate limiting policy needs to be adjusted, only the configuration parameters of the corresponding port shaper need to be modified, and the weight allocation logic of the port scheduling layer remains unaffected. Conversely, when the bandwidth allocation ratio of each port needs to be adjusted, only the weight configuration of the port scheduling layer needs to be modified, and the rate limiting parameters of each port shaper remain unchanged. This decoupled design avoids the problem of "a change in one affects the whole system" when scheduling and shaping are bound at the same level in traditional ETS systems: in traditional solutions, adjusting the rate limiting parameters of any port often requires reconfiguring the entire scheduling tree, which is complex and prone to configuration errors. Through the independent configuration of this invention, the scheduling policy and the shaping policy can be optimized and adjusted independently, significantly reducing the complexity of system operation and maintenance and the risk of configuration errors.

[0047] In a specific example, assuming the chip's total bandwidth is 400Gbps and four ports participate in scheduling, with weighted round-robin weights configured as W0=2, W1=1, W2=1, and W3=0.5 respectively, the grant token allocation ratio for port 0 is R0=2 / (2+1+1+0.5)=2 / 4.5≈44.4%, meaning port 0 receives approximately 177.6Gbps of grant tokens; ports 1 and 2 each receive approximately 88.9Gbps; and port 3 receives approximately 44.4Gbps. If the port shaper for port 0 is configured to 50Gbps, then the actual grant tokens received by port 0 will be limited to 50Gbps. The remaining unused grant tokens can be used by other ports, demonstrating the independent rate-limiting effect of the shaper.

[0048] Step 102: The authorization tokens obtained by each port are distributed to each traffic category by the traffic category scheduling layer according to the scheduling configuration of each traffic category. The committed rate shaper limits the upper limit of committed authorization tokens according to the committed rate of each traffic category, and the additional rate shaper limits the upper limit of additional authorization tokens according to the additional rate of each traffic category. Each traffic category consumes committed authorization tokens first, and consumes additional authorization tokens after the committed authorization tokens are used up.

[0049] like Figure 1 As shown, each port node connects downwards to the tc_7 and tc_0 nodes, indicating that each port is configured with multiple traffic categories (this example shows two traffic categories, tc_7 and tc_0, but more can be configured in practice). The connection lines between each port node and the tc node are labeled SP (Strict Priority), RR (Round-Robin), and WFQ (Weighted Fair Queuing), indicating that the port-level credit scheduler distributes authorization tokens to each traffic category according to the configured scheduling policy. Each tc node is connected to two shaper symbols, corresponding to the committed rate shaper (C bucket, the shaper corresponding to the blue line in the diagram) and the additional rate shaper (E bucket, the shaper corresponding to the yellow line in the diagram), indicating that each traffic category must undergo rate limiting control through two independent shapers, C bucket and E bucket, when receiving authorization tokens.

[0050] Furthermore, before the traffic category scheduling layer distributes the authorization tokens obtained by each port to each traffic category according to the scheduling configuration of each traffic category, it also performs the following sub-steps:

[0051] Step 102.1: Obtain the current token count of the first token bucket (C bucket) corresponding to the committed authorization token in each traffic category.

[0052] Step 102.2: When the current number of tokens in the first token bucket is greater than zero, grant authorization tokens are allocated to the first token bucket first.

[0053] Step 102.3: When the current token quantity in the first token bucket is zero, allocate an authorization token to the second token bucket (E bucket) corresponding to the additional authorization token.

[0054] After the port-level allocation in step 101, the authorization token obtained by each port needs to be further allocated among the various traffic categories under that port. Traffic categories are user-defined service grouping levels, and each port is fixedly configured with multiple traffic categories (e.g., ...). Figure 1 As shown in tc_7 and tc_0), different traffic categories can correspond to different types of business traffic (such as storage business, video business, ordinary data business, etc.).

[0055] The committed rate shaper and the additional rate shaper form a dual-bucket shaping mechanism at the traffic category level. The committed authorization token corresponding to the committed rate shaper represents the basic bandwidth guarantee (C bucket) for the traffic category, while the additional authorization token corresponding to the additional rate shaper represents the elastically expanded bandwidth (E bucket) for the traffic category. The two shapers are configured independently and do not affect each other.

[0056] In converged network scenarios within data centers, a single port may simultaneously handle various service types, including storage traffic (such as FCoE), real-time interactive traffic (such as video conferencing), and general data traffic. Storage traffic is extremely sensitive to packet loss and requires stable bandwidth to avoid read / write timeouts; real-time interactive traffic is sensitive to latency and requires minimum bandwidth to prevent buffering; general data traffic has fluctuating bandwidth requirements but relatively lower real-time requirements. Furthermore, all types of traffic exhibit varying degrees of burstiness: storage backup tasks may cause instantaneous high bandwidth usage during specific periods, and video streaming services may experience sudden traffic spikes during peak hours.

[0057] If only a single rate cap is configured (C bucket only), when a traffic category experiences a sudden surge in traffic, it will either be subject to hard rate limiting, resulting in packet loss or latency, or it will crowd out bandwidth for other categories. By setting up E buckets, each traffic category, while receiving its promised bandwidth guarantee, can flexibly borrow additional bandwidth when other categories have idle bandwidth. This mechanism realizes the core design philosophy of ETS: a traffic type can only use additional bandwidth if other traffic types do not occupy its allocated bandwidth. Therefore, each service type can obtain a minimum bandwidth guarantee to avoid interference from other sudden traffic surges, and can also flexibly expand using idle bandwidth when it generates its own sudden traffic surges, thereby improving overall bandwidth utilization while ensuring stable coexistence of multiple services.

[0058] Furthermore, each traffic category prioritizes the consumption of committed authorization tokens, consuming additional authorization tokens only after the committed authorization tokens are exhausted. The logic behind this order is that committed rates correspond to the basic bandwidth guarantee for the service and should be satisfied first; additional rates correspond to bursty or elastic bandwidth demands and can only be used after the basic bandwidth demand is met. Simultaneously, by recording the token bucket status of each traffic category in real time through the traffic category credit register, the system can accurately obtain the current token quantity for each traffic category before each allocation, thus ensuring the precise execution of the "prioritize consumption of committed authorization tokens" strategy.

[0059] In a specific example, a certain port is configured with three traffic categories: TC0 (storage service), TC1 (video service), and TC2 (general data service). TC0 has a committed rate of 30Gbps and an additional rate of 50Gbps; TC1 has a committed rate of 20Gbps and an additional rate of 40Gbps; and TC2 has a committed rate of 10Gbps and an additional rate of 30Gbps.

[0060] When a port receives a 100Gbps authorization token, the system first checks the first token bucket (committed token bucket) for each traffic category. Assuming that the committed token buckets of TC0 and TC1 are exhausted (current token quantity is zero), and the committed token bucket of TC2 still has remaining tokens, the system prioritizes allocating authorization tokens to the committed token bucket of TC2 until it reaches the 10Gbps limit. Then, it allocates authorization tokens to the additional token buckets for each traffic category according to the configuration. Through this mechanism, each traffic category first obtains the authorization token corresponding to its committed bandwidth, ensuring a minimum bandwidth guarantee; only after its committed bandwidth requirement is met can it consume additional authorization tokens to handle sudden traffic surges or obtain more bandwidth.

[0061] Step 103: The authorization tokens obtained by each traffic category are distributed to their respective priorities by the priority scheduling layer according to the scheduling configuration of each priority, forming tokens in each token bucket. Each token bucket is uniquely identified by a port identifier, a traffic category identifier, and a priority identifier.

[0062] like Figure 1 As shown, nodes tc_7 and tc_0 are connected downwards to priority nodes pri_7, pri_6, pri_2, and pri_0, respectively, indicating that each traffic category has a fixed number of priorities (usually 8, numbered 0 to 7). The RR, SP, and WFQ labels between the tc and pri nodes indicate that the traffic category credit scheduler allocates authorization tokens to each priority level according to the configured scheduling policy.

[0063] Specifically, the priority scheduling layer supports three scheduling methods:

[0064] When the priority scheduling layer is configured with strict priority scheduling, authorization tokens are assigned to each priority level in descending order of priority.

[0065] When the priority scheduling layer is configured with round-robin scheduling, each priority level within the same scheduling group takes turns obtaining the authorization token.

[0066] When the priority scheduling layer is configured with weighted fair queue scheduling, each priority within the same scheduling group receives an authorization token according to the weight ratio configured by the user.

[0067] After the traffic category-level allocation in step 102, the authorization token obtained for each traffic category needs to be further allocated among the priorities within that traffic category. Each traffic category has a fixed set of multiple priorities (e.g., ...). Figure 1 As shown in pri_7, pri_6, pri_2, and pri_0, different priorities correspond to different service levels of data flow. Figure 1 The RR marker between pri_7 and pri_6 indicates that these two priorities use round-robin scheduling, the SP marker below pri_6 indicates strict priority scheduling, and the WFQ marker between pri_2 and pri_0 indicates weighted fair queue scheduling, demonstrating the flexibility of using multiple scheduling algorithms in the same system.

[0068] Strict priority scheduling is suitable for latency-sensitive critical services (such as voice and video conferencing). High-priority queues receive all authorization tokens first when there is data to be sent, ensuring that critical services receive the lowest possible latency service. Round-robin scheduling is suitable for scenarios where priorities are of equal importance. Authorization tokens are distributed equally among priorities within the same scheduling group, achieving fair scheduling. Weighted fair queue scheduling balances priority differences with fairness; higher-priority queues receive a larger proportion of authorization tokens, but lower-priority queues also receive a certain proportion of authorization tokens according to their weight.

[0069] Figure 1 The simultaneous presence of RR, SP, and WFQ scheduling labels between the TC and PRI nodes indicates that this invention supports the mixed configuration of multiple scheduling algorithms within different priority groups of the same traffic category. The key advantage of this mixed scheduling capability lies in the diverse service requirements of different services—voice services require SP to ensure minimum latency, multiple services of the same priority level require RR to ensure fairness, and services of different importance require WFQ to achieve differentiated bandwidth allocation. By flexibly combining multiple scheduling algorithms within the same system, this invention eliminates the need to design separate scheduling hardware for different service types; a single architecture can adapt to various service requirements, reducing chip design complexity and area overhead.

[0070] In a specific example, four priorities (pri_0, pri_1, pri_2, pri_3) under a certain traffic category are configured for weighted fair queue scheduling, with weights configured as W0=1, W1=2, W2=3, and W3=4, respectively. The total number of authorization tokens obtained for this traffic category is 100Gbps. Therefore, pri_0 receives 100×1 / (1+2+3+4)=10Gbps, pri_1 receives 20Gbps, pri_2 receives 30Gbps, and pri_3 receives 40Gbps. If the scheduling method for pri_3 is changed to strict priority scheduling, then pri_3 will receive all authorization tokens first, and the remaining tokens will be distributed to pri_0 through pri_2 according to WFQ.

[0071] After being allocated through three levels of scheduling—port scheduling, traffic category scheduling, and priority scheduling—the total bandwidth authorization token is finally distributed to token buckets, each uniquely identified by a port identifier, traffic category identifier, and priority identifier. Each token bucket corresponds to a unique triple (port, traffic category, priority), which determines the complete scheduling path of the data flow within the three-level scheduling structure and is the sole basis for locating the target token bucket when subsequent data flows arrive.

[0072] Step 104: When the data stream arrives, locate the target token bucket based on the port identifier, traffic category identifier, and priority identifier corresponding to the data stream, and determine the authorization token for the data stream based on the current number of tokens in the target token bucket.

[0073] like Figure 1 As shown, the reverse path for determining the data flow authorization token is pri node → tc node → port node → chip node, corresponding to the signaling flow of requesting tokens from higher layers level by level when the target token bucket is insufficient. (See appendix) Figure 2 The credit status register in the system summarizes the status of each level of token bucket (including the current number of tokens in each token bucket, whether it is in a token shortage state, etc.) and provides it to the data stream processing module for authorization determination. At the same time, the status information is fed back to each level of the scheduling layer to assist in scheduling decisions.

[0074] Specifically, the priority identifier corresponding to the data stream is determined as follows: extract the value of the differential service code point field or priority code point field in the data stream message, and map the extracted field value to the corresponding priority identifier according to the pre-configured mapping table.

[0075] Furthermore, authorization token determination is performed on the data stream based on the current number of tokens in the target token bucket, including:

[0076] Step 104.1: Obtain the current number of tokens in the target token bucket.

[0077] Step 104.2: When the current number of tokens is not less than the amount of data in the data stream, allow the data stream to proceed and deduct the corresponding number of tokens from the target token bucket.

[0078] Step 104.3: When the current number of tokens is less than the amount of data in the data stream, block the data stream.

[0079] In a specific example, a data stream packet is 1500 bytes long, and the current token count in its target token bucket is 2048 bytes. Since 2048 ≥ 1500, the data stream is allowed to pass, and 1500 bytes are deducted from the target token bucket, leaving 548 bytes. If the next data stream is also 1500 bytes long, the current token count (548 < 1500) will cause this data stream to be blocked and wait.

[0080] Furthermore, when the current number of tokens in the target token bucket is less than the amount of data in the data stream, the following sub-steps are also included:

[0081] Step 104.4: The target token bucket sends the first request signal to the priority scheduling layer.

[0082] Step 104.5: When the priority scheduling layer does not have enough authorization tokens to allocate, it sends a second request signal to the traffic category scheduling layer.

[0083] Step 104.6: When the traffic category scheduling layer does not have enough authorization tokens to allocate, it sends a third request signal to the port scheduling layer.

[0084] Step 104.7: Each scheduling layer regenerates the authorization token according to its own scheduling algorithm based on the received request signal and distributes it to the target token bucket level by level.

[0085] When the target token bucket is insufficient, the system initiates a hierarchical request mechanism. The signaling flow of this mechanism is the opposite of the authorization token distribution flow: the target token bucket first sends a request signal to the traffic category credit scheduler. If the traffic category credit scheduler itself does not have enough authorization tokens to allocate, it continues to send a request signal to the port-level credit scheduler. If the port-level credit scheduler also does not have enough authorization tokens to allocate, it continues to send a request signal to the chip-level credit scheduler. Upon receiving the request signal, each scheduling layer regenerates authorization tokens according to its respective scheduling algorithm and distributes them hierarchically to the target token bucket, achieving dynamic, on-demand replenishment of tokens.

[0086] For example, a target token bucket may be blocking a 1500-byte data stream due to insufficient tokens. The target token bucket sends a first request signal to the traffic category credit scheduler, requesting 1500 bytes of authorization tokens. If the traffic category credit scheduler has enough allocable authorization tokens (e.g., 2000 bytes), it directly sends 1500 bytes to the target token bucket, and the data stream is allowed to pass. If the traffic category credit scheduler itself also lacks sufficient allocable authorization tokens, it continues to request tokens from higher-level schedulers until it obtains enough and then sends them down the chain of command.

[0087] This embodiment uses the above method to manage outgoing traffic as an example. When it is necessary to manage both outgoing and incoming traffic simultaneously, a token bucket group for incoming traffic can be added. The authorization token determination process for incoming traffic is the same as that for outgoing traffic, and will not be repeated here.

[0088] Accordingly, the present invention also provides a multi-level traffic scheduling and shaping system, comprising:

[0089] The architecture configuration module is used to configure a multi-level traffic scheduling and shaping architecture. This architecture comprises a three-level scheduling structure: a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer. Each scheduling layer is responsible for assigning authorization tokens at its corresponding level. Specifically, the port scheduling layer assigns authorization tokens between ports, with each port configured with a port shaper to independently limit the authorization token issuance rate. The traffic category scheduling layer assigns authorization tokens between traffic categories within each port, with each traffic category configured with a committed rate shaper and an additional rate shaper. The committed rate shaper limits the committed authorization token issuance rate for each traffic category, and the additional rate shaper limits the additional authorization token issuance rate for each traffic category. The priority scheduling layer assigns authorization tokens between priorities within each traffic category. The shapers at each level with shapers are independently configured modules, and each shaper independently outputs control signals to limit the upper limit of authorization token issuance at its corresponding level.

[0090] The port scheduling module is used to distribute the total bandwidth authorization token to each port according to the weighted round-robin weight of each port through the port scheduling layer, and to limit the upper limit of authorization token issuance for each port according to the shaping parameters of the corresponding port through the port shaper.

[0091] The traffic category scheduling module distributes authorization tokens obtained from each port to each traffic category according to the scheduling configuration of each traffic category through the traffic category scheduling layer. It also limits the upper limit of committed authorization tokens according to the committed rate of each traffic category through the committed rate shaper, and limits the upper limit of additional authorization tokens according to the additional rate of each traffic category through the additional rate shaper. Each traffic category consumes committed authorization tokens first, and consumes additional authorization tokens after the committed authorization tokens are exhausted.

[0092] The priority scheduling module is used to allocate the authorization tokens obtained by each traffic category to their respective priorities according to the scheduling configuration of each priority level, forming tokens in each token bucket. Each token bucket is uniquely identified by a port identifier, a traffic category identifier, and a priority identifier.

[0093] The data stream processing module is used to locate the target token bucket based on the port identifier, traffic category identifier, and priority identifier corresponding to the data stream when it arrives, and to determine the authorization token for the data stream based on the current number of tokens in the target token bucket.

[0094] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0095] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0096] In an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided.

[0097] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: entirely in hardware, entirely in software (including firmware, microcode, etc.), or in a combination of hardware and software, collectively referred to herein as “circuit,” “module,” or “system.”

[0098] An electronic device according to this embodiment of the invention. The electronic device is merely an example and should not be construed as limiting the functionality or scope of the embodiments of the invention.

[0099] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and buses connecting different system components (including memory and processor).

[0100] The memory stores program code that can be executed by a processor, causing the processor to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of the present invention.

[0101] The storage may include readable media in the form of volatile storage, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0102] The storage may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more applications, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0103] A bus can represent one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus architectures.

[0104] The electronic device can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be performed via input / output (I / O) interfaces. Furthermore, the electronic device can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0105] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0106] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0107] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0108] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0109] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0110] Furthermore, the accompanying drawings are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention and are not intended to be limiting. It is readily understood that the processes shown in the above drawings do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0111] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0112] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A multi-level traffic scheduling and shaping method, characterized in that, The method is applied to a multi-level traffic scheduling and shaping architecture, which includes a three-level scheduling structure consisting of a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer. Each scheduling layer is used to perform the allocation of authorization tokens at the corresponding level. The port scheduling layer is used to perform authorization token allocation between ports. Each port is configured with a port shaper to independently limit the authorization token issuance rate of each port. The traffic category scheduling layer is used to perform authorization token allocation between traffic categories under each port. Each traffic category is configured with a committed rate shaper and an additional rate shaper. The committed rate shaper is used to limit the committed authorization token issuance rate of each traffic category, and the additional rate shaper is used to limit the additional authorization token issuance rate of each traffic category. The priority scheduling layer is used to perform authorization token allocation between priorities under each traffic category. The shapers and scheduling layers at corresponding levels are independently configured modules, and each shaper independently outputs control signals to limit the upper limit of authorization token issuance at the corresponding level. The method includes: The port scheduling layer distributes the total bandwidth authorization tokens to each port according to the weighted round-robin weight of each port; the port shaper limits the upper limit of authorization tokens issued to each port according to the shaping parameters of the corresponding port. The authorization tokens obtained by each port are allocated to each traffic category by the traffic category scheduling layer according to the scheduling configuration of each traffic category; the committed rate shaper limits the upper limit of committed authorization tokens according to the committed rate of each traffic category, and the additional rate shaper limits the upper limit of additional authorization tokens according to the additional rate of each traffic category. Each traffic category consumes committed authorization tokens first, and consumes additional authorization tokens after the committed authorization tokens are used up. The authorization tokens obtained by each traffic category are allocated to each priority according to the scheduling configuration of each priority by the priority scheduling layer, forming tokens in each token bucket; each token bucket is uniquely identified by a port identifier, a traffic category identifier, and a priority identifier; When a data stream arrives, the target token bucket is located based on the port identifier, traffic category identifier, and priority identifier corresponding to the data stream, and the authorization token is determined for the data stream based on the current number of tokens in the target token bucket.

2. The method according to claim 1, characterized in that, Before the traffic category scheduling layer allocates the authorization tokens obtained by each port to each traffic category according to the scheduling configuration of each traffic category, it also includes: Get the current number of tokens in the first token bucket corresponding to the committed authorization token in each traffic category; When the current number of tokens in the first token bucket is greater than zero, an authorization token is allocated to the first token bucket first. When the current token quantity in the first token bucket is zero, an authorization token is allocated to the second token bucket corresponding to the additional authorization token.

3. The method according to claim 1, characterized in that, When the priority scheduling layer is configured with strict priority scheduling, authorization tokens are allocated to each priority level in descending order of priority. When the priority scheduling layer is configured with round-robin scheduling, each priority level in the same scheduling group takes turns to obtain the authorization token. When the priority scheduling layer is configured with weighted fair queue scheduling, each priority within the same scheduling group receives an authorization token according to the weight ratio configured by the user.

4. The method according to claim 1, characterized in that, The port scheduling layer distributes the total bandwidth authorization token to each port according to the weighted round-robin weight of each port, including: Based on the weighted polling weight values ​​of each port Determine the authorization token allocation ratio for each port. , The following conditions must be met: ； Where N is the total number of ports. and These are the weighted polling weights for the i-th and j-th ports, respectively; i and j are both port indices, with values ​​ranging from [0, N-1]. According to the specified authorization token allocation ratio, the total bandwidth authorization tokens are allocated to each port.

5. The method according to claim 1, characterized in that, The authorization token determination of the data stream based on the current number of tokens in the target token bucket includes: Get the current number of tokens in the target token bucket; When the current number of tokens is greater than or equal to the amount of data in the data stream, the data stream is allowed and the corresponding number of tokens is deducted from the target token bucket; When the current number of tokens is less than the amount of data in the data stream, the data stream is blocked.

6. The method according to claim 5, characterized in that, When the current number of tokens in the target token bucket is less than the amount of data in the data stream, the method further includes: The target token bucket sends a first request signal to the priority scheduling layer; When the priority scheduling layer has insufficient authorization tokens to allocate, it sends a second request signal to the traffic category scheduling layer. When the traffic category scheduling layer does not have enough authorization tokens to allocate, it sends a third request signal to the port scheduling layer. Each scheduling layer regenerates the authorization token according to its own scheduling algorithm based on the received request signal and distributes it to the target token bucket level by level.

7. The method according to claim 1, characterized in that, Also includes: Obtain the actual amount of data sent after the data stream has undergone subsequent processing; When the actual amount of data sent is greater than the number of tokens deducted from the target token bucket, the difference in number of tokens is deducted from the target token bucket.

8. The method according to claim 1, characterized in that, The priority identifier corresponding to the data stream is determined in the following way: Extract the values ​​of the differential service code point field or priority code point field from the data stream message; The extracted field values ​​are mapped to the corresponding priority identifiers according to the pre-configured mapping table.

9. The method according to claim 1, characterized in that, The multi-level traffic scheduling and shaping architecture also includes a user configuration channel, which is used to receive user-configured scheduling parameters and shaping parameters and send them to each level of scheduling layer and each level of shaper. The user configuration channel is independent of the data stream transmission channel. The port scheduling layer supports configuring weighted round-robin weights for each port; The traffic category scheduling layer supports configuring the association between each traffic category and priority, as well as configuring round-robin scheduling or weighted fair queue scheduling. The priority scheduling layer supports configuring strict priority scheduling, round-robin scheduling, or weighted fair queue scheduling; when configured as weighted fair queue scheduling, it also supports configuring the weight ratio of each priority.

10. A multi-level traffic scheduling and shaping system, characterized in that, include: The architecture configuration module is used to configure a multi-level traffic scheduling and shaping architecture, which includes a three-level scheduling structure consisting of a port scheduling layer, a traffic category scheduling layer, and a priority scheduling layer. Each scheduling layer is used to execute the allocation of authorization tokens at the corresponding level. The port scheduling layer is used to perform authorization token allocation between ports. Each port is configured with a port shaper to independently limit the authorization token issuance rate of each port. The traffic category scheduling layer is used to perform authorization token allocation between traffic categories under each port. Each traffic category is configured with a committed rate shaper and an additional rate shaper. The committed rate shaper is used to limit the committed authorization token issuance rate of each traffic category, and the additional rate shaper is used to limit the additional authorization token issuance rate of each traffic category. The priority scheduling layer is used to perform authorization token allocation between priorities under each traffic category. The shapers and scheduling layers at corresponding levels are independently configured modules, and each shaper independently outputs control signals to limit the upper limit of authorization token issuance at the corresponding level. The port scheduling module is used to distribute the total bandwidth authorization token to each port according to the weighted round-robin weight of each port through the port scheduling layer, and to limit the upper limit of authorization token issuance for each port according to the shaping parameters of the corresponding port through the port shaper. The traffic category scheduling module is used to allocate the authorization tokens obtained by each port to each traffic category according to the scheduling configuration of each traffic category through the traffic category scheduling layer, and limit the upper limit of the promised authorization tokens according to the promised rate of each traffic category through the promised rate shaper, and limit the upper limit of the additional authorization tokens according to the additional rate of each traffic category through the additional rate shaper. Each traffic category consumes the promised authorization tokens first, and consumes the additional authorization tokens after the promised authorization tokens are used up. The priority scheduling module is used to allocate the authorization tokens obtained by each traffic category to each priority according to the scheduling configuration of each priority through the priority scheduling layer, forming tokens in each token bucket. Each token bucket is uniquely identified by a port identifier, a traffic category identifier, and a priority identifier. The data stream processing module is used to locate the target token bucket according to the port identifier, traffic category identifier and priority identifier corresponding to the data stream when the data stream arrives, and to determine the authorization token for the data stream based on the current number of tokens in the target token bucket.

Images