A token bucket based traffic control method and network device

Abstract

The embodiment of the present application provides a token bucket-based flow control method and network equipment, which are used for flow control on messages passing through the network equipment. Tokens are periodically added to the token bucket, and the number of tokens added in each period is an integer multiple of a natural number power of 2; when a message passes through the network equipment, tokens are deducted from the token bucket according to the length of the message, wherein the number of tokens deducted each time is an integer multiple of a natural number power of 2. According to the above technical solution, the number of tokens added and the number of tokens deducted are both integer multiples of a natural number power of 2, so they can be accurately obtained through the shift operation of hardware, without introducing a divider or taking an approximate value. Therefore, the token bucket-based flow control method provided by the embodiment of the present application can achieve accurate flow control while consuming low hardware resources.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a token bucket-based flow control method and network device. Background Technology

[0002] The token bucket algorithm is a common network traffic shaping and rate limiting algorithm. It evaluates the relationship between the rate of traffic passing through network devices and the user-configured rate, thereby controlling the traffic rate based on this relationship.

[0003] A token bucket can be visualized as a bucket that stores tokens. Network devices are configured to fill the bucket with tokens at a rate set by the user, with each token corresponding to a certain amount of traffic. When traffic passes through the network device, the device deducts a token from the bucket corresponding to the amount of traffic. When the token bucket is depleted, no more traffic can pass through the network device.

[0004] The rate at which network devices add tokens to the token bucket is determined by the number of tokens added, while the specific number of tokens deducted each time is determined by the number of tokens deducted. Currently, network devices rely on division operations to calculate the number of tokens added and deducted. For hardware, performing division operations consumes significant resources and places high demands on hardware complexity and computing power. Summary of the Invention

[0005] This application provides a token bucket flow control method and network device that can reduce the consumption of hardware resources by the token bucket algorithm and achieve higher flow control accuracy.

[0006] Firstly, embodiments of this application provide a token bucket-based flow control method for controlling the flow of packets passing through a network device. The method includes: periodically adding tokens to the token bucket, wherein the number of tokens added in each period is an integer multiple of a power of 2; and when a packet passes through the network device, deducting tokens from the token bucket according to the length of the packet, wherein the number of tokens deducted each time is an integer multiple of a power of 2. (Token addition count, token deduction count)

[0007] According to the above technical solution, both the number of tokens added and the number of tokens deducted are integer multiples of the natural power of 2. Therefore, they can be accurately obtained through hardware shift operations without the need to introduce a divider or take approximate values. Thus, the token bucket-based flow control method provided in this application embodiment can achieve precise flow control while consuming low hardware resources.

[0008] In one implementation, the number of tokens added must be an integer multiple of a natural power of 2, including: the number of tokens added equals the product of a natural power of 2 and the expected bandwidth of the token bucket, where the expected bandwidth is an integer. Thus, the token bucket-based flow control method provided in this application can achieve precise flow control at the integer level.

[0009] In one implementation, the token deduction number is a multiple of a natural power of 2, including: the token deduction number is equal to the product of a natural power of 2 and the clock frequency of the token bucket, where the clock frequency is an integer. Thus, the token bucket-based flow control method provided in this application embodiment can perform flow control based on an integer-level clock frequency.

[0010] In one implementation, the number of tokens added is obtained using the following formula:

[0011]

[0012] Where: TokenAdd is the number of tokens added; ΔCycleCnt is the number of clock cycles in the token bucket corresponding to each token addition cycle; n is the expected bandwidth; TokenUnit is the token unit in the token bucket, where the token unit represents the message length corresponding to each token; m is the clock frequency of the token bucket; the number of tokens added is equal to the product of a natural power of 2 and the expected bandwidth of the token bucket, including: the number of clock cycles being equal to a natural power of 2, and the product of the token unit and the clock frequency being equal to a natural power of 2. Thus, the token bucket-based flow control method provided in this application constrains the numerical relationship between ΔCycleCnt, the token unit, and the clock frequency, ensuring that the number of tokens added is an integer multiple of a natural power of 2.

[0013] In one implementation, the number of tokens added and the number of tokens deducted also satisfy the following relationship:

[0014] TokenAdd = n × 2 (N-X)

[0015] TokenSub = m × 2 3-X+Y

[0016] Where: n is the desired bandwidth, m is the clock frequency, N, X, and Y are all natural numbers, and X≤N, Y≥X-3.

[0017] In one implementation, the natural number Y is obtained using the following formula: Token deduction Token addition ... Number In one implementation, the natural number Y is obtained using the following formula:

[0018] Y = log2PktLen

[0019] Where PktLen is the minimum length that a message passing through a network device must meet when each token deduction is performed, and the minimum length must be a power of 2.

[0020] In one implementation, the natural number X is obtained using the following formula:

[0021] X=log2(m×TokenUnit),(X≤Y+3)

[0022] In one implementation, the natural number N is obtained using the following formula:

[0023] N = log2ΔCycleCnt, (N ≥ X)

[0024] Thus, the token bucket-based flow control method provided in this application further simplifies the calculation of token deduction and token addition based on the numerical relationship between ΔCycleCnt, token unit, and clock frequency.

[0025] In one implementation, if all packets passing through the network device are storage cell-level packets, then a token deduction is performed whenever the total length of multiple packets passing through the network device equals the minimum length. Thus, the token bucket-based flow control method provided in this application can perform flow control on packets transmitted based on cells.

[0026] In one implementation, if the length of a packet passing through the network device includes a minimum-length packet and other packets of varying lengths, and the other lengths are natural multiples of the minimum length, then a token deduction is performed each time a packet passes through the network device. Thus, the token bucket-based flow control method provided in this application can perform flow control on packets transmitted based on a series of multiples of varying lengths.

[0027] In one implementation, if the packets passing through the network device are of random length, the cumulative length of the packets passing through the network device is counted. Whenever the cumulative length is greater than or equal to the target length, and the target length is equal to a natural multiple of the minimum length, a token deduction is performed, and the target length is deducted from the cumulative length. Thus, the token bucket-based flow control method provided in this application embodiment can perform flow control on packets transmitted based on arbitrary lengths.

[0028] In one implementation, the token bucket also includes a rate grading table, which includes token bucket parameters corresponding to at least one flow control interval, so that the network device can determine the token bucket parameters based on the flow control interval to which the desired bandwidth belongs.

[0029] In one implementation, each flow control interval includes token bucket parameters comprising one or more of the following: token unit, first cycle quantity, natural number N, natural number X, bandwidth increment granularity, minimum token addition corresponding to the bandwidth increment granularity, range of token additions corresponding to the flow control interval, and range of desired bandwidth corresponding to the flow control interval. Thus, when a user configures a desired bandwidth, the network device can select the appropriate token bucket parameters based on the flow control interval containing the desired bandwidth to precisely control the traffic.

[0030] Secondly, embodiments of this application provide a network device, including a memory and a processor. The memory stores computer program instructions, which, when executed by the processor, cause the network device to perform the methods described in the first aspect and its various implementations.

[0031] Thirdly, this application also provides a computer storage medium. This computer storage medium contains computer instructions that, when executed on a computer, cause the computer to perform the methods described in the above aspects and their implementations.

[0032] Fourthly, this application also provides a computer program product containing instructions that, when run on a computer, causes the computer to perform the methods in the above aspects and their implementations. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the token bucket algorithm;

[0034] Figure 2 This is a schematic diagram of the structure of a network device shown in an embodiment of this application;

[0035] Figure 3 This is a schematic diagram illustrating the limiting conditions of the token bucket parameters in an embodiment of this application;

[0036] Figure 4 This is a flowchart illustrating the normalization process for the message length PktLen as shown in an embodiment of this application;

[0037] Figure 5 This is a schematic diagram illustrating the cumulative message length and token deduction in an embodiment of this application;

[0038] Figure 6 This is the token bucket rate level table provided in the embodiments of this application. Detailed Implementation

[0039] The token bucket algorithm is a common network traffic shaping and rate limiting algorithm. It evaluates the relationship between the rate of traffic passing through network devices and the user-configured rate, thereby controlling the traffic rate based on this relationship.

[0040] Figure 1 This is a schematic diagram of the token bucket algorithm. (For example...) Figure 1 As shown, the token bucket 10 can be visualized as a bucket storing tokens 11. The network device is configured to add (or fill) tokens 11 into the bucket at a user-configured rate, with each token corresponding to a certain amount of traffic 12. When traffic 12 passes through the network device, the network device deducts tokens 11 corresponding to the amount of traffic 12 from the bucket. If no traffic 12 passes through for a long time, the number of tokens 11 in the bucket will reach a certain limit, and any tokens 11 added to the bucket after that will be discarded. If the traffic 12 passing through the network device is fast and exhausts all the tokens 11 in the bucket, then traffic 12 cannot continue to pass through the network device until a new token 11 is added to the bucket; it can only be buffered or discarded. Therefore, through the token bucket algorithm, the network device can control the rate of traffic passing through the network device according to the user-configured rate.

[0041] To facilitate those skilled in the art in understanding the technical solutions of the embodiments of this application, the relevant concepts involved in the token bucket algorithm are listed and explained below:

[0042] 1. Tokens and their units of measurement.

[0043] ① Define a token as Token. One token is one Token. Therefore, the value of Token represents the number of tokens in the token bucket. This number of tokens is actually the difference between the expected packet traffic through the network device and the actual packet traffic through the network device.

[0044] ② Define the unit of tokens as TokenUnit. TokenUnit represents the amount of traffic that a network device can handle for each unit (each) of tokens. TokenUnit is usually measured in bits / Token. For example, when TokenUnit = 16bit / Token, it means that a network device can handle 16 bits of traffic, or 2 bytes, for one token.

[0045] 2. Concepts related to token filling.

[0046] In the token bucket algorithm, network devices periodically fill the token bucket with a certain number of tokens over time; this is called token filling. The token filling operation involves the following concepts:

[0047] ① The clock frequency at which tokens are filled into the token bucket (i.e., the token bucket filling clock frequency) is defined as Freq (Frequency). Freq is usually expressed in Hertz (Hz), including GHz, MHz, etc. For example, Freq = 1000MHz.

[0048] ② Define the period corresponding to the token bucket filling clock frequency as Period, which is usually measured in seconds (s). Period can be understood as the reciprocal of Freq; for example, when Freq = 1000Hz, Period = 0.001s.

[0049] ③ Define a certain time interval as ΔT, which is usually expressed in seconds (s).

[0050] ④ Define the number of clock cycles (Periods) corresponding to a certain time interval ΔT as ΔCycleCnt. For ΔCycleCnt, we obviously have formula (1):

[0051]

[0052] ⑤ Define the expected bandwidth as BW (BandWidth), where expected bandwidth BW represents the rated bandwidth of the network device for the traffic a user expects to configure. Expected bandwidth BW is typically measured in bits per second (bits per second), bps (bits per second), kbps (kilobits per second), Mbps (megabits per second), and Gbps (gigabits per second).

[0053] ⑥ Define TokenAdd as the number of tokens added to the bucket within a certain time interval ΔT. TokenAdd represents the number of tokens corresponding to the packet traffic allowed to pass through the network device according to the expected bandwidth BW within a certain time interval ΔT. For TokenAdd, according to the principle of token filling, there is obviously formula (2):

[0054]

[0055] 3. Concepts related to token deduction.

[0056] In the token bucket algorithm, when a packet passes through a network device, a number of tokens corresponding to the packet traffic need to be deducted from the bucket; this is called token deduction. The token deduction operation involves the following concepts:

[0057] ① Define the length of the message as PktLen (Packet Length). Here, PktLen can refer to the length of the message corresponding to one token deduction. It can be the length of one message or the length of multiple messages. PktLen is usually in bytes.

[0058] ② Define the token deduction number TokenSub when performing token deduction. TokenSub can specifically represent the number of tokens equivalent to the message length PktLen of a single token deduction.

[0059] Based on the equivalence between message length PktLen and token deduction number TokenSub, the following formula (3) can be obtained:

[0060]

[0061] In formula (3), since the unit of message length PktLen is Byte and the unit of TokenUnit is bit / Token, the two are not consistent. Therefore, the unit of message length PktLen can be converted to bit first. According to 1Byte = 8bit, PktLen can be multiplied by 8 to convert it to bit unit. Next, PktLen × 8 is divided by TokenUnit to obtain the token deduction number TokenSub.

[0062] Based on the above explanation of the relevant concepts in 1 to 3, and formulas (1) to (3), the working principle of the token bucket can be further described as follows: with the expected bandwidth BW, at a time interval ΔT, tokens of quantity TokenAdd are filled into the bucket; when a message passes through, the number of tokens TokenSub corresponding to the message length PktLen is deducted from the bucket; if the tokens in the bucket are exhausted, the message cannot continue to pass through until a new token is put into the bucket, thus achieving the goal of the token bucket algorithm: controlling the message passing rate to the expected bandwidth BW.

[0063] The token bucket algorithm is a common method for implementing flow control. One of the most important indicators for evaluating the quality of flow control is its accuracy. In the case of the token bucket algorithm, this accuracy refers to the precision of the token bucket. In one implementation, accuracy can be expressed as an error rate. A higher error rate indicates worse accuracy, and vice versa. For example, accuracy can be expressed using the following formula (4):

[0064]

[0065] In formula (4), BW exp BW represents the user's desired bandwidth. cfg This indicates the hardware limitations of the network device, specifically the actual configurable bandwidth. Due to these hardware limitations, BW exp With BW cfg The actual values ​​may not be equal, resulting in the Accurate value not being 0, meaning there is an error.

[0066] Generally, in scenarios where token bucket accuracy requirements are not high, an accuracy of less than 0.5% may be sufficient. However, with the development of network technology, more fields require token bucket accuracy to reach zero error, meaning the actual configurable bandwidth (BW) of the network device must be zero. cfg and the user's expected bandwidth BW exp They are completely equal. However, based on the existing hardware, implementing a token bucket with zero error or a high-precision token bucket requires a large amount of hardware resources and places high demands on the complexity of the hardware itself and its computing power.

[0067] To better understand the relationship between token bucket precision and hardware resource consumption, the following explanation uses a commonly used token bucket with a divider as an example.

[0068] Taking a token bucket with a expected traffic of BW = 1Mbps as an example, assuming the token unit is 1 bit / Token and the clock frequency is Freq = 1GHz, then by combining formulas (1) and (2) and substituting the parameter values, we can obtain formula (5):

[0069]

[0070] Therefore, in each filling period, the network device's hardware can use the divider in Formula 5 to perform a division operation to accurately obtain the number of tokens to be filled, TokenAdd.

[0071] However, for hardware, introducing a divider leads to significant hardware resource consumption. To avoid introducing a divider and reduce hardware resource consumption, in some scenarios where precision is not high, the division calculation in formula (5) can be converted into a calculation that is easier for the hardware to handle. The conversion process is shown in formula (6):

[0072]

[0073] Combining formula (6), specifically, since the data exists in the hardware in binary encoding form, the 1000 in formula (5) can be replaced with a power of 2 that is close to its value, such as 2. 10 =1024; Thus, in hardware coding, TokenAdd can be obtained by performing a shift operation on ΔCycleCnt, for example, shifting it 10 bits to the left (i.e., <<10 in the formula).

[0074] It can be seen that by using hardware shift operations, the use of a divider can be avoided, reducing the hardware resource consumption of the token bucket algorithm. However, since the conversion process involves approximate changes in values, the TokenAdd actually calculated by formula (6) does not correspond precisely to the user's expected bandwidth BW. For example, converting 1000 to 1024 will make the actual number of tokens filled in each filling period (Period) smaller than expected. Therefore, the bandwidth actually configured by the token bucket algorithm is lower than the user's expected bandwidth BW. The specific accuracy can be calculated by formula (7):

[0075]

[0076] As can be seen from formula (7), in the example where the expected flow rate is BW = 1 Mbps, the token unit is 1 bit / Token, and the clock frequency is Freq = 1 GHz, the accuracy of the current shift operation scheme is 2.34%. This accuracy may be applicable in scenarios where the flow control accuracy requirement is not high, but it is seriously insufficient in scenarios where the flow control accuracy requirement is high.

[0077] Therefore, given the current hardware, the token bucket algorithm cannot achieve precise traffic control while consuming relatively few hardware resources. To address this technical problem, this application provides a token bucket-based traffic control method, also known as the token bucket algorithm, which can achieve precise traffic control, such as error-free traffic control, while consuming relatively few hardware resources.

[0078] The token bucket provided in this application embodiment can be implemented based on hardware, such as a network device. Figure 2 This is a schematic diagram of the structure of a network device shown in an embodiment of this application. Figure 2 As shown, the network device can specifically be a router, switch, network host, or server, etc., and can act as a forwarding device to forward packets between upstream and downstream nodes. The network device may include a memory 310, a communication interface 320, and a processor 330. The memory 310, communication interface 320, and processor 330 are coupled together. The memory 310 stores program instructions, and the processor 330 can call the program instructions in the memory 310 to cause the network device to execute relevant methods, such as parsing packets, generating packets, receiving and forwarding packets through the communication interface 320, and implementing flow control through token buckets, etc.

[0079] In this embodiment, the processor 330 of the network device may include one or more processing units, such as a system-on-a-chip (SoC), a central processing unit (CPU), a microcontroller (MCU), a memory controller, etc. Different processing units may be independent devices or integrated into one or more processors.

[0080] In this embodiment, the network device's memory 310 may include one or more memory units, such as volatile memory (DRAM), static random access memory (SRAM), etc.; and non-volatile memory (NVM), such as read-only memory (ROM), flash memory, etc. Different memory units may be independent devices, or they may be integrated or packaged into one or more processors or communication interfaces, becoming part of the processor or communication interface.

[0081] In this embodiment, the communication interface 320 of the network device may include, for example, a network adapter, a network interface card (NIC), a LAN adapter, a network interface controller (NIC), a modem, etc. The communication interface may be a separate device, or it may be partially or wholly integrated into or packaged within the processor, becoming part of the processor.

[0082] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the network device. In other embodiments of this application, the network device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0083] The basic idea of ​​the token bucket algorithm provided in this application is to implement the division operation involved in calculating the token bucket fill amount (TokenAdd) and the token deduction amount (TokenSub) through a shift operation. This reduces the hardware resource consumption of the token bucket algorithm and achieves accurate calculation of the token bucket fill amount, thus improving flow control accuracy. To achieve the purpose of the shift operation, such as... Figure 3 As shown, the parameters of the token bucket in this embodiment of the application are limited as follows:

[0084] Constraint 1: The number of clock cycles ΔCycleCnt corresponding to the constraint time interval ΔT is equal to a power of 2, that is, the time interval for token filling is a power of 2 clock cycles.

[0085] Limitation 2: The product of the token unit (TokenUnit) and the clock frequency (Freq) is constrained, i.e., TokenUnit × Freq equals a power of 2.

[0086] Constraint 3: To achieve constraint 2, TokenUnit can be a decimal so that TokenUnit × Freq equals a natural power of 2.

[0087] Limitation 4: Normalize the message length to a power of 2.

[0088] Thus, on the one hand, when the token bucket parameters satisfy the limitation of 1 to 3, according to formula (5), the calculation process of the token addition number TokenAdd can be completely implemented through hardware shift operations, and no approximate value is required. Therefore, the consumption of hardware resources by the token bucket algorithm is reduced, and an accurate integer value of the token addition number TokenAdd can be obtained. On the other hand, when the token bucket parameters satisfy the limitation of 4, according to formula (3), the calculation process of the token deduction number TokenSub can be completely implemented through hardware shift operations, and no approximate value is required. Therefore, the consumption of hardware resources by the token bucket algorithm is reduced, and an accurate integer value of the token deduction number TokenSub can be obtained. It can be seen that, through the limitations of the embodiments of this application, both the token addition number TokenAdd and the token deduction number TokenSub are accurate integer values, and both are obtained through hardware shift calculations, which reduces the consumption of hardware resources by the token bucket algorithm and makes the flow control more accurate.

[0089] The following section will explain in detail the basis for determining the limits 1 to 4, using some derivation and calculation processes as well as some examples:

[0090] First, in order to ensure that the calculation of the token deduction number TokenSub can be fully implemented through hardware shift operations, the embodiments of this application set ΔCycleCnt to satisfy the following formula (8):

[0091] ΔCycleCnt=2 N (N is a natural number) (8)

[0092] Understandably, in order for the token bucket algorithm to achieve precise bandwidth control, the token bucket algorithm must be able to perform precise token filling and precise token deduction operations according to user expectations. Since the hardware adds and deducts tokens in the form of integer tokens, in order to achieve precise token filling and precise token deduction operations, the calculation results of formulas (2) and (3) must be integers, that is, the number of tokens added (TokenAdd) and the number of tokens deducted (TokenSub) must both be integers.

[0093] The following description, based on the limitations of ΔCycleCnt in the embodiments of this application, further explains the conditions that the token addition number TokenAdd and the token deduction number TokenSub must meet.

[0094] a. The conditions that TokenAdd must meet:

[0095] First, the expected bandwidth (BW) of the token bucket is set to n Mbps, and the clock frequency (Freq) of the token bucket is set to m MHz. Here, n and m can be natural numbers or other values, and this embodiment does not limit them. Generally, when users need to configure network devices for traffic control, they usually control the traffic with integers, such as controlling the traffic to 100Mbps, 500Mbps, 1Gbps, etc. Therefore, this embodiment focuses on the case where n and m are natural numbers.

[0096] Therefore, the expected bandwidth BW and clock frequency Freq satisfy the following formula (9):

[0097]

[0098] It should be noted that the units of expected bandwidth BW (Mbps) and clock frequency Freq (MHz) are only examples here. They only mean that the token bucket provided in this application embodiment can accurately control traffic based on an integer clock frequency Freq in MHz and an expected bandwidth in Mbps. They do not constitute a limitation on the units of expected bandwidth BW and clock frequency Freq. The units of expected bandwidth BW and clock frequency Freq can be changed according to user configuration.

[0099] Next, substituting formulas (8) and (9) into formula (5), we can obtain the following formula (10).

[0100]

[0101] From formula (10), it can be seen that when ΔCycleCnt satisfies formula (8), if the token addition number TokenAdd is to be obtained through a shift operation, then TokenUnit × Freq can be equal to a natural power of 2. Furthermore, if we want TokenAdd to be an integer, then m × TokenUnit can satisfy the following formula 11:

[0102] m×TokenUnit=2 X (X≤N, and X is a natural number) (11)

[0103] Thus, due to 2 N Divide by 2 X Equal to 2 (N-X) When N is a natural number, X≤N, and X is a natural number, NX is an integer, and n is also an integer. Therefore, it can be guaranteed that the number of tokens added, TokenAdd, is an integer. Specifically, substituting formula (11) into formula (10), we can obtain that the number of tokens added, TokenAdd, satisfies the following formula (12):

[0104]

[0105] b. Conditions that TokenSub must satisfy:

[0106] According to formula (11), we have:

[0107]

[0108] Because of 2 X Dividing by m does not necessarily result in an integer. Therefore, to ensure that multiplying TokenUnit by m (i.e., Freq) yields 2... X TokenUnit can be a decimal.

[0109] Substituting formula (11-1) into formula (3), we can obtain the token deduction number TokenSub, which satisfies the following formula (13):

[0110]

[0111] As can be seen from formula (13), when m takes any natural number, in order to make the token deduction number TokenSub an integer, PktLen×2 (3-X) It also needs to be a natural number, and, in order to enable the token deduction number TokenSub to be implemented by shift operations when implemented in hardware, PktLen can satisfy formula (14):

[0112] PktLen=2 Y(Y≥X-3, and Y is a natural number) (14)

[0113] Furthermore, by combining equations (13) and (14), we can obtain that the token deduction number TokenSub satisfies equation (15):

[0114] TokenSub = m × 2 3-X+Y (15)

[0115] As can be seen from formula (14), in order to ensure that the token deduction number TokenSub meets the integer requirement, this application embodiment also imposes some constraints on the message length PktLen, that is, the message length PktLen should meet 2. Y However, generally speaking, the packet length PktLen passing through a network device can be any value; it may be a fixed length or a variable length. Therefore, when the packet length passing through a network device does not satisfy PktLen = 2... Y In this embodiment of the application, the packet length PktLen of the network device's dequeue can be normalized to ensure that PktLen = 2. Y That is, satisfying the constraint of formula (14) to ensure that the token deduction number TokenSub is an integer each time. The specific implementation of constraining the message length PktLen to satisfy formula (14) will be further explained in subsequent embodiments.

[0116] In summary, as described in a and b, when the user configures the expected bandwidth BW of the token bucket to be n Mbps and the clock frequency Freq to be m MHz, the corresponding token addition number TokenAdd and token subtraction number TokenSub can be calculated simply by using the following formula (16) (including formulas (12) and (15)):

[0117]

[0118] Where N, X, and Y are all natural numbers, and X≤N, Y≥X-3.

[0119] As can be seen from formula (16), since n and m are constants when the expected bandwidth BW and clock frequency Freq are set, the token add number TokenAdd and the token subtract number TokenSub can be precisely implemented by shifting n and m by left or right shifting operations, without the need to introduce a divider. This allows the token bucket algorithm to achieve precise control of traffic while consuming less hardware resources.

[0120] Further, it can be seen from formula (16) that N, X, and Y are all natural numbers, and there are infinitely many combinations of X≤N and Y≥X-3, which means that the token addition number TokenAdd and the token deduction number TokenSub can have an infinite number of values. In order to facilitate those skilled in the art to specifically determine any set of values ​​for the token addition number TokenAdd and the token deduction number TokenSub, the following embodiments of this application provide an exemplary description of the ways in which N, X, and Y are selected.

[0121] For Y, according to formula (14), Y can be obtained by constraining the message length PktLen to be a power of 2, that is, Y satisfies formula (17):

[0122] Y = log2PktLen (17)

[0123] Therefore, once the message length PktLen is determined, the value of Y can be randomly determined.

[0124] For example: when the message length PktLen is 32 bytes, the value of Y is 5; when the message length is 128 bytes, the value of Y is 7; when the message length is 1024 bytes, the value of Y is 10.

[0125] For X, according to formula (11), X can be obtained by constraining the value of TokenUnit, and simultaneously satisfy X≤Y+3, that is, X satisfies formula (18):

[0126] X=log2(m×TokenUnit),(X≤Y+3) (18)

[0127] Since m is known and TokenUnit is an arbitrary value defined by the user, it is easy to determine a value of TokenUnit such that X satisfies the constraints.

[0128] For example, when m = 1000: if the value of Y is 5, then TokenUnit = 0.128, and X = 7; if the value of Y is 5, then TokenUnit = 0.256, and X = 8; if the value of Y is 7, then TokenUnit = 0.128, and X = 7; if the value of Y is 7, then TokenUnit = 0.256, and X = 8.

[0129] Therefore, for the same Y value, the corresponding X value can be the same or different, depending on the selected TokenUnit value. The Y value limits the maximum value of X. For different Y values, the corresponding X values ​​can also be the same or different, depending on the selected TokenUnit value. The Y value only limits the maximum value of X to be different.

[0130] For N, according to formula (8), N can be obtained by constraining ΔCycleCnt to be a natural power of 2, that is, N satisfies formula (19):

[0131] N=log2ΔCycleCnt, (N≥X) (19)

[0132] Since ΔCycleCnt is an arbitrary value defined by humans, it is easy to determine a value of ΔCycleCnt such that N satisfies the constraints.

[0133] For example, when X = 7, since N ≥ X, ΔCycleCnt can be set to 256, in which case N = 8; or ΔCycleCnt can be set to 512, in which case N = 9; or ΔCycleCnt can be set to 1024, in which case N = 10.

[0134] Therefore, for the same X value, different N values ​​can be set. Since N corresponds to the value of ΔCycleCnt, the larger N is, the larger the time interval ΔT for adding tokens to the token bucket is, and the larger the corresponding number of tokens added TokenAdd is. The smaller N is, the smaller the time interval ΔT for adding tokens to the token bucket is, and the smaller the corresponding number of tokens added TokenAdd is.

[0135] It is understandable that, since the message length PktLen of a network device can be any value—it could be a fixed length or a variable length—and may or may not satisfy the condition that PktLen equals a power of 2, the token bucket in this application embodiment can employ different normalization methods for messages of different message lengths PktLen. The following will elaborate on three specific implementation methods for the message length PktLen.

[0136] In the first implementation, the message length PktLen is a fixed value, and it satisfies that the message length PktLen is equal to a natural power of 2.

[0137] Generally, if the dequeueing of network devices is based on the granularity of memory cells, then the message length PktLen can be normalized to a fixed value. A memory cell is typically the smallest unit of memory, and each cell can store one bit. Therefore, if the dequeueing of messages is based on the granularity of memory cells, it means that messages are dequeued at the bit level. Since a bit is also the smallest unit of a message, any message length PktLen can be normalized at the bit level. To facilitate the calculation of token deductions, this embodiment normalizes the message length PktLen to a fixed value.

[0138] For the first implementation method, taking a clock frequency Freq of 1000MHz (m=1000), a desired bandwidth BW of 1Mbps (n=1), and a fixed message length PktLen of 128 bytes as an example:

[0139] From formula (17), we can obtain:

[0140] Y = log₂128 = 7 (20)

[0141] According to formula (18), the value of X is greater than or less than Y+3, that is, X≤10. Therefore, the value X = 10 can be taken here. Then, according to m = 1000, the TokenUnit is 1.024. Then, according to formula (18), we can get:

[0142] X=log2(1000×1.024)=10 (21)

[0143] According to formula (19), the value of N is greater than or less than X, that is, N≥10. The ΔCycleCnt value that can satisfy this constraint can be, for example, 1024. Then, according to formula (19), we can obtain:

[0144] N = log₂1024 = 10 (22)

[0145] Next, substituting the determined values ​​of Y, X, and N into formula (16), we obtain:

[0146]

[0147] Thus, for the implementation with a clock frequency Freq = 1000MHz and a message length PktLen = 128Byte (fixed value), when configuring the token bucket, simply configuring TokenUnit = 1.024 and ΔCycleCnt = 1024 will yield a precise token bucket with a desired bandwidth BW = 1Mbps, enabling precise control of traffic.

[0148] In the second implementation, the message length PktLen may have multiple values, where the minimum message length PktLen is the most significant. min It equals the natural power of 2, i.e., PktLen min =2 Y The remaining values ​​for message length are the minimum message length, PktLen. min Any integer multiple of the length. For example, the minimum message length PktLen. min = 128 bytes, other message lengths can include 256 bytes, 384 bytes, 512 bytes, 640 bytes, 768 bytes, 896 bytes, 1024 bytes, etc.

[0149] For the second implementation, with a clock frequency Freq of 1000MHz (m=1000), a desired bandwidth BW of 1Mbps (n=1), and a minimum message length PktLen min = 128 bytes for example:

[0150] Using the minimum message length PktLen min =128 bytes determines the value of Y, then according to formula 19, we can get:

[0151] Y = log₂128 = 7 (24)

[0152] According to formula (18), the value of X is greater than or less than Y+3, that is, X≤10. Therefore, the value X = 10 can be taken here. Then, according to m = 1000, the TokenUnit is 1.024. Then, according to formula (18), we can get:

[0153] X=log2(1000×1.024)=10 (25)

[0154] According to formula (19), the value of N is greater than or less than X, that is, N≥10. The ΔCycleCnt value that can satisfy this constraint can be, for example, 1024. Then, according to formula (19), we can obtain:

[0155] N = log₂1024 = 10 (26)

[0156] Substituting the determined values ​​of X and N into formula (16) to determine the number of tokens to be added (TokenAdd), we get:

[0157] TokenAdd = 1 × 2 (10-10) =1 (27)

[0158] As can be seen from formulas (25)-(27), since the token bucket filling operation does not involve the message length, only the values ​​of X and N are used when determining the token addition number TokenAdd. Therefore, compared with the first implementation method, the values ​​of X and N in the second implementation method can remain unchanged, so the token addition number TokenAdd also remains unchanged. For the token deduction operation, as shown in formula (24), it can be based on the minimum message length PktLen. min Once the value of Y is determined, the token deduction number TokenSub can be determined in the following way:

[0159] First, for all message lengths PktLen except the minimum message length, we have:

[0160] PktLen=PktLen min ×Z=2 Y ×Z (28)

[0161] Where Z is a positive integer, indicating that the length of the remaining messages is an integer multiple of the minimum message length.

[0162] Substituting formula (28) into formula (13), we can obtain the formula for calculating the token deduction TokenSub, which changes to formula (29):

[0163] TokenSub = m × PktLen × 2 3-X =m×Z×2 3-X+Y (29)

[0164] Next, substituting the determined values ​​of Y, X, and N into formula (29), we obtain:

[0165] TokenSub = 1000 × Z × 2 3-10+7 =1000×Z (30)

[0166] By comparing formulas (23) and (30), it can be seen that when the message length is the minimum value PktLen min When the length is an integer multiple of the given value, the token deduction number TokenSub is actually the minimum message length PktLen. min The minimum token deduction amount (1000 in this example) must be an integer multiple of the minimum token deduction amount. Therefore, it is only necessary to use the minimum message length PktLen. min Once the minimum token deduction is determined, the token deduction TokenSub corresponding to the lengths of the remaining messages can be easily determined.

[0167] In the third implementation, the message length PktLen can be any value. For any message length PktLen, it can be normalized to the value shown in formula (14) as 2. Y Length, or processed as shown in formula (28) 2 Y ×Z length. Thus, the third implementation is equivalent to either the first or second implementation, and the methods used in the first and second implementations can be used to determine the token addition (TokenAdd) and token deduction (TokenSub).

[0168] Figure 4 This is a flowchart illustrating the normalization process for the message length PktLen as shown in an embodiment of this application.

[0169] like Figure 4 As shown, normalizing the message length PktLen can be achieved through the following steps:

[0170] Step S1: Define the minimum message length PktLen_min, where the minimum message length PktLen_min is a power of 2.

[0171] Step S2: Define the cumulative packet length QueLen of packets entering the packet queue of the network device.

[0172] The initial value of the cumulative message length QueLen is 0.

[0173] Step S3: When a message enters the message queue, the message length PktLen is incremented into QueLen, i.e.:

[0174] QueLen = QueLen + PktLen.

[0175] Understandably, as packets continuously enter the packet queue, the cumulative packet length QueLen can be continuously incremented, such as... Figure 5 As shown, when message 1, message 2 and message 3 enter the message queue in sequence, the cumulative message length QueLen can be the sum of the lengths of message 1, message 2 and message 3.

[0176] Step S4: When the number of tokens in the token bucket is greater than 0, the message is allowed to be dequeued. In this implementation, as... Figure 5As shown, when the cumulative message length QueLen is greater than 0, and whenever the cumulative message length QueLen is greater than or equal to a positive integer multiple of the minimum message length PktLen_min, i.e., QueLen≥PktLen_min×Z, the token amount corresponding to the message PktLen_min×Z is deducted from the token bucket. That is, if the token amount in the token bucket is insufficient for deduction or the token amount is 0, message dequeueing can be paused. After the token amount in the token bucket is greater than the token amount corresponding to the message PktLen_min×Z, the deduction is performed again, and message dequeueing is resumed.

[0177] Step S5: The network device records the cumulative packet length QueLen after deducting the remaining part of PktLen_min×Z, that is:

[0178] QueLen = QueLen - PktLen_min × Z

[0179] When subsequent messages enter the queue, continue executing steps S3-S5. For example... Figure 5 As shown, when another message 4 enters the message queue, the cumulative message length QueLen is equal to the sum of the remaining length after the last deduction and the length of message 4. If the cumulative message length QueLen is once again greater than or equal to a positive integer multiple of the minimum message length PktLen_min, then the deduction continues.

[0180] In this way, although the length of the message arriving at the network device is not the minimum message length PktLen_min, the token bucket of this application embodiment can normalize the message to a positive integer multiple of the minimum message length PktLen_min, and deduct tokens based on the amount of tokens corresponding to a positive integer multiple of the minimum message length PktLen_min, thereby achieving precise bandwidth control.

[0181] It should be noted that in the third implementation, although the token deduction is performed using a positive integer multiple of the minimum message length PktLen_min, the message can be dequeued in advance with the minimum message length PktLen_min before the token deduction. This can reduce the latency between the message entering and leaving the queue.

[0182] In another implementation, based on limitations 1 to 4, embodiments of this application can set different TokenUnit and ΔCycleCnt values ​​for different traffic control intervals to obtain token bucket parameters corresponding to different traffic control intervals. These token bucket parameters can be stored in the network device in the form of a token bucket rate level table. When a user configures a certain desired bandwidth BW, the network device selects the corresponding token bucket parameters according to the traffic control interval where the desired bandwidth BW is located to precisely control the traffic.

[0183] Taking a clock frequency of Freq = 1000MHz as an example, a token bucket rate level table is as follows: Figure 6 As shown:

[0184] from Figure 6 The token bucket rate tier table shown illustrates that the overall flow control range of the token bucket, from 0.5Mbps to 2Gbps, is divided into four rate tiers, namely:

[0185] Rate class K3: 0.5Mbps to 4Mbps, supporting bandwidth values ​​increasing in granularity of 15.625Kbps.

[0186] Rate class K2: 4Mbps to 32Mbps, supporting bandwidth values ​​increasing in 125Kbps granularity.

[0187] Rate class K1: 32Mbps to 256Mbps, supporting bandwidth values ​​that increase in 1Mbps increments.

[0188] Rate class K0: 256Mbps to 2Gbps, supporting bandwidth values ​​increasing in 8Mbps increments.

[0189] According to the token bucket rate grading table, the expected bandwidth BW satisfies the following formula (30):

[0190]

[0191] The following explanation uses rate level K0 as an example to illustrate the various parameters in the token bucket rate level table:

[0192] in:

[0193] To satisfy the condition that TokenUnit × Freq equals a natural power of 2, TokenUnit = 1.024 is determined in rate class K0.

[0194] To satisfy the condition that ΔCycleCnt equals a natural power of 2, ΔCycleCnt = 128 is determined in rate class K0.

[0195] According to formula (8), N = 7 can be determined. According to formula (18), X = 10 can be determined, at which point X > N. According to formula (12), when X > N, if n is any value, it cannot be guaranteed that TokenAdd will always be a positive integer. Therefore, it may be necessary to limit n. If TokenAdd takes the minimum value of 1, according to formula (12), n has a minimum value of n = 8. This minimum value of n can be called the bandwidth increment granularity, which means that the bandwidth increment granularity n = 8 Mbps corresponds to the rate level K0. It can be seen that TokenAdd = 1 is the minimum number of tokens added corresponding to the bandwidth increment granularity n = 8 Mbps.

[0196] Additionally, Cfg_Token represents the number of tokens that need to be added to the token bucket every ΔCycleCnt clock cycles (time interval ΔT) according to the desired bandwidth BW. Different Cfg_Token values ​​correspond to different desired bandwidths BW. In the token bucket rate class table, Cfg_Token is set between 32 and 255, with a minimum value of Cfg_Token_min = 32, corresponding to a minimum desired bandwidth BW_min = 256Mbps, and a maximum value of Cfg_Token_max = 255, corresponding to a maximum desired bandwidth BW_max = 2040Mbps. In this way, rate class K0 can achieve flow control in 8Mbps granularity between the desired bandwidth of 256Mbps and 2Gbps.

[0197] For example, when the desired bandwidth is 800Mbps, the rate level K0 can be determined according to the token bucket rate level table, and Cfg_Token = 100 can be determined according to formula (30). The calculation formula is as shown in (31).

[0198]

[0199] The determination of parameters in other rate levels is similar to that of rate level K0, and will not be repeated here. It should be noted that Table 1 shown in this embodiment is merely an example of a token bucket rate level table. The parameters in the token bucket rate level table can vary according to changes in parameters such as clock frequency Treq and desired bandwidth BW range, and do not constitute a specific limitation on the embodiments of this application. Therefore, any modifications and improvements to the token bucket rate level table by those skilled in the art, such as adding or reducing rate levels, adjusting arbitrary parameters, or implementing the function of the token bucket rate level table in any other form, such as through hardware circuitry, do not exceed the protection scope of this application embodiment.

[0200] This application also provides a computer storage medium. This computer storage medium contains computer instructions that, when executed on a computer, cause the computer to perform the methods described in the above aspects and their implementations.

[0201] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in the above aspects and their implementations.

[0202] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A token bucket based flow control method, characterized in that, A method for flow control of packets passing through a network device, the method comprising: adding tokens to a token bucket periodically at intervals of a time interval, the number of tokens added per interval being an integer multiple of a natural number power of 2, wherein the time interval is a natural number power of 2 clock cycles, the product of a token unit and a clock frequency being a natural number power of 2, the token unit representing the size of the flow that the network device can pass per unit token, and the number of tokens added being implemented by a shift operation of hardware; when a packet passes through the network device, deducting tokens from the token bucket according to the length of the packet, wherein the number of tokens deducted each time is an integer multiple of a natural number power of 2, and the number of tokens deducted is implemented by a shift operation of hardware.

2. The method of claim 1, wherein, The number of tokens added being an integer multiple of a natural number power of 2 comprises that the number of tokens added is equal to the product of a natural number power of 2 and the value of the expected bandwidth of the token bucket, and the expected bandwidth is an integer.

3. The method of claim 2, wherein, The number of tokens deducted being an integer multiple of a natural number power of 2 comprises that the number of tokens deducted is equal to the product of a natural number power of 2 and the clock frequency of the token bucket, and the clock frequency is an integer.

4. The method according to claim 2 or 3, characterized in that, The number of tokens added is obtained by the following formula: ； in: Add a number to the token; The number of clock cycles in the token bucket corresponding to each period in which a token is added; n is the expected bandwidth; The token unit is the token unit of the token bucket, where the token unit represents the message length corresponding to each token; The clock frequency of the token bucket; The number of tokens added being equal to the product of a natural number power of 2 and the value of the expected bandwidth of the token bucket comprises that the number of clock cycles is equal to a natural number power of 2, and the product of the token unit and the clock frequency is equal to a natural number power of 2.

5. The method according to claim 2 or 3, characterized in that, The number of tokens added and the number of tokens deducted also satisfy the following relationship: ； ； Wherein: n is the expected bandwidth, m is the clock frequency, N, X, Y are natural numbers, and X≤N, Y≥X-3.

6. The method of claim 5, wherein, The natural number Y is obtained by the following formula: ； wherein: For each time the token deduction is executed, the minimum length of the packet passing through the network device needs to meet, the minimum length meets the natural number power of 2.

7. The method of claim 5, wherein, The natural number X is obtained by the following formula: 。 8. The method of claim 5, wherein, The natural number N is obtained by the following formula: 。 9. The method of claim 6, wherein, If all the packets passing through the network device are cell granularity packets, the token deduction is performed once every time the total length of multiple packets passing through the network device is equal to the minimum length.

10. The method of claim 6, wherein, If the lengths of the packets passing through the network device include packets of the minimum length and packets of other lengths, and the other lengths are natural number multiples of the minimum length, the token deduction is performed once every time a packet passes through the network device.

11. The method of claim 6, wherein, If the packets passing through the network device are random length packets, the cumulative length of the packets passing through the network device is counted; The token deduction is performed once every time the cumulative length is greater than or equal to a target length, and the target length is a natural number multiple of the minimum length, and the target length is deducted from the cumulative length.

12. The method of claim 2 or 3, wherein, The token bucket further comprises a rate level table, the rate level table comprising token bucket parameters corresponding to at least one flow control interval, so that the network device determines the token bucket parameters according to the flow control interval to which the expected bandwidth belongs.

13. A network device, comprising: comprising a memory storing computer program instructions and a processor, when the computer program instructions are executed by the processor, the network device is caused to perform the method of any one of claims 1-12.

Images