Token bucket verification method and system, electronic equipment and medium

Abstract

The invention provides a token bucket verification method and system, electronic equipment and a medium, and the method comprises the steps: carrying out the initialization configuration of to-be-tested equipment according to first preset configuration information, and carrying out the periodic token filling according to the initialized to-be-tested equipment, so as to execute the bucket filling verification of each token bucket; performing initialization configuration on the to-be-tested device and the reference model of the first mode based on second preset configuration information, and inputting the same message information to the initialized to-be-tested device and the initialized first mode model to execute bucket buckling verification of each token bucket; and performing initialization configuration on the to-be-tested device and the reference model of the second mode based on third preset configuration information, and inputting the same mixed message information to the initialized to-be-tested device and the initialized second mode model to execute rate verification of each token bucket. According to the method, token bucket verification is carried out in three steps, and universal verification can be realized for token bucket algorithms of various different protocols.

Description

Technical Field

[0001] This application belongs to the technical field of performance testing, and relates to a token bucket verification method, in particular to a token bucket verification method, system, electronic device and medium. Background Art

[0002] The token bucket algorithm is a commonly used algorithm in the QoS (Quality of Service) function of switches (the algorithm process is as Figure 1 shown), and can be applied to various technologies such as interface rate limiting, traffic policing, and traffic shaping. Its basic principle is to simulate a token bucket with a configurable bucket depth: the system adds tokens to it at a fixed rate, and the number of tokens can be filled up to the same as the bucket depth at most, and the excess part will overflow and be discarded. Each token represents a certain amount of permission for the flow to pass through. Whenever a packet enters the token bucket for arbitration, an evaluation of the forwarding permission will be performed on it. If the tokens in the token bucket are sufficient at this time, the packet passing through the bucket will consume the number of tokens corresponding to the packet forwarding permission and obtain the passing permission. Conversely, if the number of tokens is insufficient, the packet will be discarded or back-pressured and other restricted forwarding processes will be performed. From the above information, it can be seen that the filling rate of the tokens is the maximum rate at which the flow allowed to flow to the token bucket can pass through, and the bucket depth is the promised maximum burst value. In actual applications, multiple token buckets often need to be maintained at the same time. Therefore, in the design and implementation, generally, a class of token bucket information with the same function will be stored in the same piece of RAM. After enabling the token bucket function through configuration, the system reads the token bucket information in the RAM and writes it back to the RAM after calculating the new filling value. The system will periodically traverse all addresses and complete the refresh of each token bucket in turn. When a packet is received, the token bucket address corresponding to the packet will be parsed, and the token bucket information will be read from the corresponding address in the RAM and the deducted value will be calculated and also written back to the RAM. This process will read and write the corresponding addresses in a fixed time sequence according to the order in which the packets are received to complete the refresh of the token bucket. Note that during the process of reading and writing the RAM, both filling and deduction will only refresh the value of the number of tokens in the token bucket, and will not modify the configuration information. The filling rate and bucket depth of the token bucket will only be affected by the configuration path. From the above information, it can be seen that in addition to verifying the addition and subtraction logic of a single or multiple token buckets inherent in the algorithm itself, how to fully verify the read and write conflicts when adding and deducting token buckets is also a very important part.

[0003] So how should the token bucket algorithm be verified? When first approaching verification, verifiers typically aim for input-output consistency. This means applying various random stimuli and different configurations. If the output from the DUT (Device Under Test) consistently matches expectations (and compares consistently with the reference model), verification is considered passed. While this approach is reasonable, directly applying it to token bucket algorithm testing presents two problems. First, if the reference model is to ensure that every packet is processed identically to the DUT, then the addition and removal of all token buckets must be simulated in perfect sync, with the timing perfectly aligned with the DUT. This process is complex and overly dependent on the timing of token addition and removal by the DUT. Second, even if the correct processing of every packet is guaranteed, does that mean the token bucket algorithm design has achieved its intended effect? The answer is clearly no. Whether it's interface rate limiting or traffic policing, they're essentially macro-level controls on classified traffic. Verifying only at a micro level is only half the battle. What if, instead, we approach this from the outset by conducting macro-level monitoring to verify that the output rate meets expectations? This does directly address the ultimate goal of verification, but in actual operation, two difficult-to-solve problems arise. First, if a bug exists in the DUT, this verification method can often only monitor the expected traffic rate over a long period of time and cannot accurately locate the time point when the bug first appeared, resulting in inefficient bug finding and repair. Second, if the module incorporates other functions besides the token bucket algorithm, such as packets lost in the front stage not entering the token bucket arbitration, packets authorized by the token bucket being discarded by the packet loss logic in the back stage, or some special packets being allowed to skip the token bucket algorithm and pass directly, the more these functions are mixed, the more difficult it is to predict the final output flow rate, increasing the difficulty of testing. However, if mixed scenarios are not tested, some bugs may be missed. Therefore, the direct macro-monitoring testing method also has its limitations. Summary of the Invention

[0004] The present application provides a token bucket verification method, system, electronic device and medium, which are used to solve the problem that the existing token bucket verification method is difficult to be applied to the verification of token bucket algorithms of different protocols at the same time.

[0005] In the first aspect, the present application provides a token bucket verification method, the method comprising: initializing and configuring a device to be tested according to first preset configuration information, periodically filling tokens according to the initialized device to be tested to perform bucket filling verification of each token bucket; the first preset configuration information includes a token bucket depth and a token bucket filling rate; the device to be tested includes at least one token bucket; initializing and configuring the device to be tested and a reference model of the first mode based on second preset configuration information, inputting the same message information to the initialized device to be tested and the initialized first mode model respectively to perform bucket buckling verification of each token bucket; the second preset configuration information includes a token bucket depth and a token bucket filling rate; the device to be tested includes at least one token bucket; the device to be tested and a reference model of the first mode are initialized and configured based on second preset configuration information, and the same message information is input to the initialized device to be tested and the initialized first mode model respectively to perform bucket buckling verification of each token bucket; the second preset configuration information includes a token bucket depth and a token bucket filling rate; the device to be tested includes at least one token bucket; the device to be tested and a reference model of the first mode are initialized and configured based on second preset configuration information, and the device to be tested and the initialized first mode model are initialized respectively to perform bucket buckling verification of each token bucket; the depth and the initial number of tokens in the token bucket; the reference model is a model that implements the same function as the device under test; the first mode is a mode in which packet comparison is turned on and flow classification collection and comparison are turned off in the reference model; based on the third preset configuration information, the device under test and the reference model of the second mode are initialized and configured respectively, and the same mixed message information is input into the initialized device under test and the initialized second mode model respectively to perform rate verification of each token bucket; the third preset configuration information includes the token bucket depth, the token bucket filling rate and the initial number of tokens in the token bucket; the second mode is a mode in which packet comparison is turned off and flow classification collection and comparison are turned on in the reference model.

[0006] In an implementation of the first aspect, periodically filling tokens according to the initialized device to be tested to perform bucket filling verification of each token bucket includes: periodically filling tokens according to the initialized device to be tested to obtain filling token information; the filling token information includes the current number of tokens between adjacent cycles in the filling process of each token bucket and the current number of tokens after the filling is completed; comparing the current number of tokens between adjacent cycles in the filling process of each token bucket and the current number of tokens after the filling is completed with the first preset configuration information to implement bucket filling verification of each token bucket.

[0007] In an implementation of the first aspect, the filling verification of each token bucket is realized by comparing the current number of tokens between each adjacent cycle during the filling process of each token bucket and the current number of tokens after the filling is completed with the first preset configuration information, including: obtaining the token number increment between each cycle of each token bucket according to the current number of tokens between each adjacent cycle during the filling process of each token bucket; obtaining the comparison result by comparing the token number increment between each cycle of each token bucket and the current number of tokens after the filling is completed with the first preset configuration information; if the token number increment between each cycle of each token bucket is the same as the token bucket filling rate in the first preset configuration information, and the current number of tokens after the filling of each token bucket is the same as the token bucket depth in the first preset configuration information, then the comparison result is that the filling verification of each token bucket is passed; otherwise, the comparison result is that the filling verification of each token bucket is failed.

[0008] In an implementation of the first aspect, inputting the same message information into the device under test after initialization and the first mode model after initialization to perform the token bucket deduction verification for each token bucket includes: obtaining first output information of the device under test according to the message information input by the device under test after initialization; the message information includes at least one message; the first output information of the device under test includes output packets corresponding to each message; obtaining first mode model output information according to the same message information input by the first mode model after initialization; the first mode model output information includes output packets corresponding to each message; performing packet comparison on the output packets corresponding to each message in the first output information of the device under test and the output packets corresponding to each message in the first mode model output information respectively to implement the token bucket deduction verification for each token bucket.

[0009] In an implementation of the first aspect, the output packets corresponding to each message include message marking information of the current message and the remaining token number of the hit token bucket; performing packet comparison on the output packets corresponding to each message in the first output information of the device under test and the output packets corresponding to each message in the first mode model output information respectively to implement the token bucket deduction verification for each token bucket includes: comparing the message marking information of the current message and the remaining token number of the hit token bucket in the output packets corresponding to each message in the first output information of the device under test with the message marking information of the current message and the remaining token number of the hit token bucket in the output packets corresponding to each message in the first mode model output information respectively to obtain a comparison result; if the message marking information of the current message in the output packets corresponding to each message in the first output information of the device under test is the same as the message marking information of the current message in the output packets corresponding to each message in the first mode model output information, and the remaining token number of the hit token bucket in the output packets corresponding to each message in the first output information of the device under test is the same as the remaining token number of the hit token bucket in the output packets corresponding to each message in the first mode model output information, then the comparison result indicates that the token bucket deduction verification for each token bucket passes; otherwise, the comparison result is that the token bucket deduction verification for each token bucket fails.

[0010] In an implementation of the first aspect, the same mixed message information is input into the initialized device to be tested and the initialized second mode model respectively to perform rate verification of each token bucket, including: obtaining the output information of the second device to be tested according to the mixed message information input into the initialized device to be tested; the mixed message information includes several messages of different priorities; the output information of the second device to be tested includes the output packet corresponding to each message; obtaining the output information of the second mode model according to the same mixed message information input into the initialized second mode model; the output information of the second mode model includes the output packet corresponding to each message; comparing the flow rate according to the output packet corresponding to each message in the output information of the second device to be tested and the output packet corresponding to each message in the output information of the second mode model to realize rate verification of each token bucket.

[0011] In an implementation of the first aspect, each message includes a message length and a token bucket number; the output packet corresponding to each message includes the message tag information of the current message and the number of remaining tokens that hit the token bucket; the flow rate is compared according to the output packet corresponding to each message in the output information of the second device under test and the output packet corresponding to each message in the output information of the second mode model to realize the rate verification of each token bucket, including: selecting the message with message tag information as the forwarded message according to the output packet corresponding to each message in the output information of the second device under test, and calculating the output flow rate corresponding to each output flow in each hit token bucket according to the message length and token bucket number of the selected message; the output flow includes messages of the same priority in each hit token bucket; the output flow rate is the sum of the message lengths of each message in the current output flow divided by the total time for the device under test to process mixed message information; the message information includes forwarding and discarding; according to The output packet corresponding to each message in the output information of the second mode model selects the message with the message marking information as the forwarded message, and calculates the output flow rate corresponding to each output flow in each hit token bucket according to the message length and token bucket number of the selected message; the output flow rate corresponding to each output flow in each hit token bucket obtained by calculating according to the output information of the second device under test is respectively compared with the output flow rate corresponding to each output flow in each hit token bucket obtained by calculating according to the output information of the second mode model to obtain a comparison result; the output flow rate corresponding to each output flow in each hit token bucket obtained by calculating according to the output information of the second device under test is the same as the output flow rate corresponding to each output flow in the same hit token bucket obtained by calculating according to the output information of the second mode model, then the comparison result is that the rate verification of each token bucket is passed; otherwise, the comparison result is that the rate verification of each token bucket is failed.

[0012] In a second aspect, the present application provides a token bucket verification system, the system comprising: a bucket filling verification module, configured to initialize and configure the device to be tested according to a first preset configuration information, and periodically fill tokens according to the initialized device to be tested to perform bucket filling verification of each token bucket; the first preset configuration information comprises a token bucket depth and a token bucket filling rate; the device to be tested comprises at least one token bucket; a bucket deduction verification module, configured to initialize and configure the device to be tested and a reference model of the first mode respectively based on a second preset configuration information, and input the same message information to the initialized device to be tested and the initialized first mode model respectively to perform bucket deduction verification of each token bucket; the second preset configuration information comprises a token bucket depth and a token bucket filling rate; the device to be tested comprises at least one token bucket; The token bucket depth and the initial token number of the token bucket; the reference model of the first mode is a model that implements the same function as the device under test; the first mode is a mode in which packet comparison is turned on and flow classification collection and comparison are turned off in the reference model; the rate verification module is configured to initialize the configuration of the device under test and the reference model of the second mode based on the third preset configuration information, and input the same mixed message information to the initialized device under test and the initialized second mode model to perform rate verification of each token bucket; the third preset configuration information includes the token bucket depth, the token bucket filling rate and the initial token number of the token bucket; the second mode is a mode in which packet comparison is turned off and flow classification collection and comparison are turned on in the reference model.

[0013] In a third aspect, the present application provides an electronic device, comprising: a processor and a memory; wherein the memory is used to store a computer program; and the processor is used to execute the computer program stored in the memory so that the electronic device performs the token bucket verification method as described above.

[0014] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned token bucket verification method when executed by an electronic device.

[0015] As described above, the token bucket verification method, system, electronic device, and medium described in this application have the following beneficial effects:

[0016] The three-step token bucket verification method proposed in this application eliminates most bugs by first breaking down the complex dynamic processing logic of the token bucket into independent bucket filling and deleting logic. These two phases are then isolated and verified separately to eliminate most bugs. Dynamic performance testing is then performed after completion, improving efficiency while ensuring the completeness of verification. These three phases of testing can not only identify different bugs, but also complement and rely on each other, enabling universal verification of token bucket algorithms across various protocols.

[0017] In the bucket filling verification stage of this application, no packets need to be sent, enabling the token bucket to always maintain a state of only increasing and never decreasing. Thus, the correctness test of the token bucket filling can be completed simply by continuously reading the token bucket at regular intervals. The modification is very small, and the reusability for token bucket verification of different protocols is relatively high.

[0018] In the bucket deduction verification stage of this application, by continuously sending packets and preventing the device under test from filling the token bucket, the token bucket always maintains a state of only decreasing and never increasing. Then, combined with the packet output result obtained from the reference model in the first mode, the correctness test of the token bucket deduction is completed. Since there is no need to handle conflicts, this process greatly simplifies the complexity of the reference model in the first mode and reduces the labor cost required for writing.

[0019] The rate verification stage of this application is relatively close to the scenario in real applications. It is necessary to combine packet sending at a certain rate with the periodic filling of the token bucket. The difficulty lies in controlling the rate of the input packets and monitoring the rate of the output stream without statistical errors. By monitoring that the rate of each output stream meets the expectations, the performance test of the token bucket is completed. Brief Description of the Drawings

[0020] Figure 1 It shows a schematic diagram of the working principle of the token bucket described in the embodiment of this application.

[0021] Figure 2 It shows a schematic diagram of the application scenario of the token bucket verification method described in the embodiment of this application.

[0022] Figure 3 It shows a schematic diagram of the flow of the token bucket verification method described in the embodiment of this application.

[0023] Figure 4 It shows a schematic diagram of the principle of single-speed double-bucket filling token described in the embodiment of this application.

[0024] Figure 5 It shows a schematic diagram of the principle of single-speed double-bucket deducting token described in the embodiment of this application.

[0025] Figure 6 It shows a flowchart of the bucket filling test described in the embodiment of this application.

[0026] Figure 7 It shows a flowchart of the bucket deduction test described in the embodiment of this application.

[0027] Figure 8 It shows a flowchart of the rate verification described in the embodiment of this application.

[0028] Figure 9 It shows a schematic diagram of the principle of RFC2697 traffic policing described in the embodiment of this application.

[0029] Figure 10 It shows a schematic structural diagram of the token bucket verification system described in the embodiments of the present application.

[0030] Figure 11 It shows a schematic structural diagram of the electronic device described in the embodiments of the present application.

[0031] Description of component numbers

[0032] 100 Electronic device

[0033] 111 Memory

[0034] 112 Storage controller

[0035] 113 Processor

[0036] 114 Peripheral interface

[0037] 115 Input / output unit

[0038] 116 Display unit

[0039] 200 Token bucket verification system

[0040] 211 Bucket filling verification module

[0041] 212 Bucket deduction verification module

[0042] 213 Rate verification module

[0043] 300 Electronic device

[0044] 311 Processor

[0045] 312 Memory

[0046] 3121 Operating system

[0047] 3122 Application program

[0048] 313 Network interface

[0049] 314 User interface

[0050] Steps S1 to S3 Specific implementation manners

[0051] The following uses specific specific examples to illustrate the implementation manners of the present application. Those skilled in the art can easily understand other advantages and effects of the present application from the content disclosed in this specification. The present application can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other.

[0052] It should be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present application in a schematic manner. The diagrams below only show the components related to the present application, rather than being drawn according to the number, shape, and size of the components in actual implementation. The types, quantities, and proportions of the components in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0053] The following embodiments of the present application provide a token bucket verification method, system, electronic device, and medium, which solve the problem that the existing token bucket verification method is difficult to be applicable to the verification of token bucket algorithms of different protocols at the same time.

[0054] The embodiment of the present application provides a token bucket verification method, which is applied to an electronic device. The electronic device can be an electronic device with logical computing functions such as a server, a personal computer (PC), a tablet computer, a smart phone, a personal digital assistant (PDA), etc., and can test the marking algorithm accordingly for different marking situations, effectively improving the effectiveness and accuracy during marking tests.

[0055] Please refer to Figure 2 , Figure 2 , which shows a block diagram of an electronic device provided by the embodiment of the present application. The electronic device 100 may include a memory 111, a storage controller 112, a processor 113, a peripheral interface 114, an input / output unit 115, and a display unit 116. Those of ordinary skill in the art can understand that Figure 2 the structure shown is only schematic and does not limit the structure of the electronic device 100. For example, the electronic device 100 may also include more or fewer components than those shown in Figure 2 , or have a different configuration from that shown in Figure 2 .

[0056] The above-mentioned components of the memory 111, storage controller 112, processor 113, peripheral interface 114, input / output unit 115, and display unit 116 are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The above-mentioned processor 113 is used to execute the executable module stored in the memory. Among them, the memory 111 can be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc. Among them, the memory 111 is used to store programs. After receiving the execution instruction, the processor 113 executes the program. The method executed by the electronic device 100 defined by the process disclosed in any embodiment of the embodiments of the present application can be applied to the processor 113 or implemented by the processor 113.

[0057] The above-mentioned processor 113 may be an integrated circuit chip with signal processing capabilities. The above-mentioned processor 113 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The above-mentioned peripheral interface 114 couples various input / output devices to the processor 113 and the memory 111. In some embodiments, the peripheral interface 114, the processor 113, and the memory controller 112 may be implemented on a single chip. In some other instances, they may be implemented by separate chips. The above-mentioned input / output unit 115 is used to provide input data to the user. The input / output unit 115 may be, but is not limited to, a mouse, a keyboard, etc. The above-mentioned display unit 116 provides an interaction interface (such as a user operation interface) between the electronic device 100 and the user or is used to display image data for the user to reference. In this embodiment, the display unit may be a liquid crystal display or a touch display. If it is a touch display, it may be a capacitive touch screen or a resistive touch screen that supports single-point and multi-point touch operations, etc. Supporting single-point and multi-point touch operations means that the touch display can sense touch operations generated simultaneously at one or more positions on the touch display and hand over the sensed touch operations to the processor for calculation and processing. In the embodiments of the present application, the display unit 116 can display data such as token bucket verification results.

[0058] The electronic device in this embodiment can be used to execute each step in the various token bucket verification methods provided in the embodiments of the present application. The implementation process of the token bucket verification method will be described in detail through several embodiments below.

[0059] The technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings in the embodiments of the present application.

[0060] As Figure 3 shown, this embodiment provides a token bucket verification method, and the method includes the following steps S1 to S3.

[0061] Step S1: Initialize the device under test according to the first preset configuration information, and perform periodic token filling on the initialized device under test to execute the bucket filling verification of each token bucket; the first preset configuration information includes the token bucket depth and the token bucket filling rate; the device under test includes at least one token bucket; the reference model includes a token bucket model; the token bucket model includes at least one token bucket.

[0062] In one implementation, initializing the device under test (DUT) according to the first preset configuration information includes: randomly configuring the token bucket depth and the token bucket filling rate of each token bucket in the token bucket model of the device under test to any reasonable value (any reasonable value is a conditional value that satisfies the condition that the initial number of tokens in the token bucket is less than or equal to the token bucket depth) according to the token bucket protocol type, and configuring the initial number of tokens in each token bucket to 0. After the configuration is completed, enable all token buckets. Among them, the difference between the token bucket depth and the token bucket filling rate should not be too large to cause too long filling time. After configuring the token bucket information such as the token bucket depth and the token bucket filling rate, the token bucket enablement also needs to be configured.

[0063] In one implementation, periodically filling tokens on the initialized device to perform bucket filling verification on each token bucket includes: periodically filling tokens on the initialized device to be tested, reading the current token number of each token bucket between the first filling cycle and the non-filling process during the first filling process, and continuing to read the current token number of each token bucket for a period of time after the first filling is completed, comparing whether the token number increment of each token bucket is equal to the filling rate based on the current token number of each token bucket read between the first filling cycle and the non-filling process during the first filling process, and comparing whether the current token number of each token bucket is always consistent with the token bucket depth after the first filling is completed. If the two are consistent, it means that the comparison is correct and the bucket filling verification of each token bucket of the device to be tested in the first filling cycle is successful. Otherwise, it means that the comparison is incorrect, there is an error in the device to be tested or the token bucket calculation is wrong. Because the device under test fills tokens periodically after initialization and configuration, only when the increment of the number of tokens in each token bucket in each filling cycle is equal to the filling rate, and the current number of tokens in each token bucket is always consistent with the depth of the token bucket after the filling is completed, it means that the filling verification of each token bucket of the device under test is successful, otherwise it means that the filling verification of each token bucket of the device under test has failed. Therefore, this application needs to read the current number of tokens in each token bucket between two filling cycles during the continuous filling process, and continue to read the current number of tokens in each token bucket for a period of time after the filling is completed. According to the current number of tokens in each token bucket read between the two filling cycles during the filling process, the increment of the number of tokens in each token bucket is compared to see whether it is equal to the filling rate, and at the same time, the current number of tokens in each token bucket is compared to see whether it is always consistent with the depth of the token bucket. If the two are consistent in each filling cycle, it means that the comparison is correct and the filling verification of each token bucket of the device under test is successful. Otherwise, it means that the comparison is incorrect, the filling verification of each token bucket of the device under test has failed, and there is an error in the filling of the bucket of the device under test or an error in the token bucket calculation.

[0064] It should be noted that the bucket filling verification in step S1 of this application must not send any messages, so that the token bucket can always remain in a state of only adding and not subtracting, so that the correctness test of the token bucket filling can be completed by continuously reading the token bucket on a periodic basis.

[0065] Step S2: Based on the second preset configuration information, the device under test and the reference model of the first mode are initialized and configured respectively, and the same message information is input into the initialized device under test and the initialized first mode model respectively to perform bucket verification of each token bucket; the second preset configuration information includes the token bucket depth and the initial number of tokens in the token bucket; the reference model is a model that implements the same function as the device under test; the first mode is a mode in which packet comparison is turned on and flow classification collection and comparison are turned off in the reference model.

[0066] In one implementation, initializing and configuring the device to be tested and the reference model of the first mode based on the second preset configuration information respectively includes: randomly configuring the token bucket depth and the initial token number of each token bucket in the token bucket model of the device to be tested to any reasonable value (any reasonable value is a conditional value that satisfies the condition that the initial token number of the token bucket is less than or equal to the token bucket depth), and configuring the token bucket filling rate of each token bucket to 0, and enabling all token buckets after the configuration is completed. At the same time, the reference model of the first mode of the verification environment is initialized with the same configuration as the device to be tested. The reference model is a model that implements the same function as the device to be tested; the first mode is a mode in which packet comparison is turned on and flow classification collection and comparison are turned off in the reference model. In the reference model of the first mode, only packet comparison is performed, and flow comparison is not performed.

[0067] In one implementation, the same message information is input into the initialized device under test and the initialized first mode model respectively to perform bucket verification of each token bucket, including: after completing the initialization configuration of the device under test and the reference model of the first mode, a number of messages are sent, the message is parsed according to each message, and the corresponding token bucket is randomly hit according to each parsed message information. After receiving the parsed message information, the first mode model will compare the number of tokens required for forwarding with the number of remaining tokens in the token bucket. If the number of remaining tokens is greater, the message is marked as forwarded, otherwise the message is marked as discarded. In this way, the message marking information of each message and the number of remaining tokens in each token bucket can be obtained. Similarly, the device under test receives each message and obtains the message marking information of each message and the number of remaining tokens in each token bucket. The message marking information of each message output by the device under test and the number of remaining tokens in each token bucket are respectively compared with the message marking information of each message and the number of remaining tokens in each token bucket output by the first mode model. If they are consistent, it means that the comparison is correct and the bucket verification of each token bucket in the device under test is successful. Otherwise, it means that the comparison is incorrect, the bucket verification of each token bucket in the device under test fails, there is an error in the device under test or the reference model is written incorrectly.

[0068] In this implementation, during the bucket verification process in step S2, the message inputs of the device under test and the first mode model are input one message at a time, so that a corresponding output is obtained respectively, that is, a message is input to the device under test, and a corresponding output packet is obtained, and a message identical to the device under test is input to the first mode model, and a corresponding output packet is obtained, and these two output packets are compared to perform bucket verification of each token bucket, that is, a packet comparison method. The output packet includes the message tag information of the current message and the number of remaining tokens that hit the token bucket, that is, the message tag information in the two output packets is the same, and the number of remaining tokens that hit the token bucket in the two output packets is also the same, which indicates that the bucket verification of the current token bucket is successful.

[0069] In addition, the message content includes the message length and the token bucket number. Among them, the token bucket number is used to select the token bucket hit by the current message. The message length is used to consume tokens. The longer the message length, the more forwarding permissions are required for the current message in the hit token bucket. However, the message content is not limited to the message length and the token bucket number, and this application does not take this as a limitation.

[0070] It should be noted that the processing method of the token bucket deduction verification in step S2 of this application is exactly the opposite of that of the token bucket filling verification in the previous stage. It is necessary to continuously send packets without allowing the device under test to fill the token bucket, so that the token bucket always maintains a state of only decreasing and not increasing. Then, combined with the message output result obtained from the reference model of the first mode, the correctness test of the token bucket deduction is completed. Since there is no need to handle conflicts, this process greatly simplifies the complexity of the reference model of the first mode and reduces the labor cost required for writing.

[0071] Step S3: Initialize and configure the device under test and the reference model of the second mode respectively based on the third preset configuration information, and input the same mixed message information into the initialized device under test and the initialized second mode model respectively to perform the rate verification of each token bucket; the third preset configuration information includes the token bucket depth, the token bucket filling rate, and the initial token number of the token bucket; the second mode is the mode in which packet comparison is turned off and flow classification collection and comparison are turned on in the reference model.

[0072] In an implementation manner, initializing and configuring the device under test and the reference model of the second mode respectively based on the third preset configuration information includes: randomly configuring the token bucket depth and the token bucket filling rate of each token bucket in the token bucket model of the device under test to any reasonable value (any reasonable value is a conditional value that satisfies the condition that the initial token number of the token bucket is less than or equal to the token bucket depth) according to the token bucket protocol type, and configuring the initial token number of each token bucket to a relatively small value. After the configuration is completed, enable all token buckets. The token bucket depth should not be too small to result in insufficient ability to handle burst traffic, nor should it be too large to result in excessive instantaneous traffic. In addition to configuring token bucket information such as the token bucket depth, the token bucket filling rate, and the initial token number of the token bucket, the token bucket enablement also needs to be configured. At the same time, make an initialization configuration of the same configuration as the device under test for the reference model of the second mode in the verification environment. The reference model of the second mode has the same number of token buckets as the device under test. The second mode is the mode in which packet comparison is turned off and flow classification collection and comparison are turned on in the reference model. In the reference model of the second mode, only flow comparison is performed, and no packet comparison is performed.

[0073] In one implementation, inputting the same mixed message information to an initialized device under test and an initialized second mode model to perform rate verification on each token bucket includes: after completing initial configuration of the device under test and the reference model of the second mode, using a rate-controllable packet sending component to simultaneously send messages at different random rates to each token bucket for a long period of time, wherein the different message rates indicate different message priorities, with higher message rates having higher priorities. During the packet sending process, after token bucket hit processing is performed on these messages, a rate monitoring component is used to distinguish each output flow corresponding to each token bucket, ensuring that different flows are not confused. After packet sending is completed, the output rate of each output flow is calculated. Here, only the output packets corresponding to each input message with message marking information indicating forwarding are counted. These output packets are identical to the output packets in the token bucket, including the message marking information of the current message and the number of remaining tokens in the token bucket. After the rate statistics of each output flow corresponding to each token bucket in the device under test and the second mode model are completed, the output flow rates of the two models are compared. If the output rates of the two output flows are the same, the rate limit capability verification of the token bucket has passed. That is, the rate verification of each token bucket in the device under test is successful. Otherwise, the rate verification of each token bucket in the device under test has failed, indicating that there is an error in the device under test or the reference model is written incorrectly.

[0074] It should be noted that the rate verification in step S3 of this application is closer to the scenario in real applications. It requires combining packet sending at a certain rate with periodic filling of the token bucket. The difficulty lies in controlling the rate of input packets and monitoring the rate of output flows without statistical errors. By monitoring the rate of each output flow to ensure that it meets the expected rate, the performance test of the token bucket is completed.

[0075] Specifically, this application proposes a new three-step verification method, which decomposes the token bucket verification into three steps: bucket filling verification, bucket deduction verification, and rate verification. This method can achieve universal verification for token bucket algorithms of various protocols.

[0076] In one embodiment, the present application verifies whether the process of filling the token bucket is correct. First, randomly configure the bucket depth and filling rate of the token bucket to any reasonable values, and configure the initial number of tokens in the token bucket to 0; after the configuration is completed, enable all token buckets. Since the addition of tokens to the token bucket is carried out in a fixed cycle, reading and writing each token bucket in turn. Therefore, after the initialization configuration is completed, it is necessary to immediately synchronize the filling cycle of the device under test (synchronization can be achieved through the internal signal of the device under test). After each signal indicating that the filling of the device under test is completed is detected, before the next filling cycle arrives, read out the number of tokens in each token bucket in turn through the configuration path and record them, repeating the operation multiple times according to the cycle. If after each filling cycle, the recorded token increment is consistent with the configured filling rate, and the number of tokens after filling is always consistent with the bucket depth in subsequent cycles, it indicates that the verification is passed. The verification in this stage must not send any packets, so that the token bucket can always maintain a state of only increasing and not decreasing, so that the correctness test of filling the token bucket can be completed only by continuously reading the token bucket according to the cycle.

[0077] In one embodiment, the present application verifies whether the token bucket deduction process is correct. This step needs to be verified with the help of the reference model of the first mode. First, all token buckets are still enabled, and the token bucket depth and the initial token number of the token bucket are randomly configured to any reasonable value (the initial token number of the token bucket may not be equal to the bucket depth), and the token bucket filling rate is configured to 0. At the same time, the same number of token buckets are also instantiated in the reference model of the first mode of the verification environment, and the same configuration and initial token number of the token bucket as the device under test are given. After completing the initialization configuration, several messages are sent to randomly hit different token buckets. When receiving the message, the reference model of the first mode will compare the number of tokens required for forwarding with the remaining tokens in the token bucket. If the remaining token number is greater, the message is marked as forwarded, otherwise the message is marked as discarded. Since the filling rate has been configured to 0, the token buckets of the device under test and the reference model of the first mode will only be deducted but not filled. Therefore, there is no need to consider the impact of the timing of filling the bucket. It is only necessary to process the corresponding token buckets in the order in which the messages are received. Even if the time nodes of the bucket decrement may not be completely consistent, it can be guaranteed that the number of remaining tokens in the token bucket of the first mode reference model and the device under test is consistent each time the message is processed. If the discard and pass marks of the messages output by the first mode reference model and the device under test are consistent, and at the end of the simulation, the remaining values of each token bucket in the device under test and the reference model of the first mode are consistent, then the verification is successful. Since there is no need for conflict handling, this process greatly simplifies the complexity of the reference model of the first mode and reduces the labor cost required for writing. The verification method of this stage is exactly the opposite of the verification method of the previous stage. It is necessary to keep sending packets and not allowing the device under test to fill the token bucket so that the token bucket is always in a state of only decreasing and not adding. Then, combined with the message output results obtained by the reference model of the first mode, the correctness test of the token bucket decrement is completed.

[0078] In one embodiment, the present application verifies whether the rate limiting ability of the token bucket is correct. Enable each token bucket, randomly configure the token bucket depth and the token bucket filling rate to any reasonable values, and configure the initial number of tokens in the token bucket to a small value. (Note: In actual applications, traffic tests are generally conducted after the token bucket is filled. However, due to the short simulation time of EDA (Electronic Design Automation), to avoid statistical errors caused by a large initial number of tokens in the token bucket allowing more traffic to pass through, tests are usually conducted immediately after configuring the initial number of tokens in the token bucket to a small value). After completing the above initialization configuration for the device under test and the reference model in the second mode, use a packet sending component with controllable rate to send flows with different random rates to each token bucket simultaneously for a relatively long period of time. During the process of sending packets, it is necessary to use a rate monitoring component to distinguish the output flows corresponding to each input flow, and different flows must not be confused. After the packet sending is completed, count the output rates of each flow. If it is found through comparison that the output rates of the output flows corresponding to the device under test are consistent with the output rates of the output flows corresponding to the reference model in the second mode, it indicates that the rate limiting ability of the token bucket has passed the verification. The verification in this last stage is relatively close to the scenario in actual applications, and it is necessary to combine packet sending at a certain rate and the periodic filling of the token bucket. The difficulty lies in controlling the rate of the input flow and monitoring the rate of the output flow without statistical errors. By monitoring that the rate of each output flow meets the expectation, the performance test of the token bucket is completed.

[0079] In one embodiment of the present application, the token bucket filling verification for each token bucket is performed by periodically filling tokens according to the initialized device under test, including the following steps S11 to S12.

[0080] Step S11: Periodically fill tokens according to the initialized device under test to obtain filling token information; the filling token information includes the current number of tokens between adjacent periods during the filling process of each token bucket and the current number of tokens after filling is completed.

[0081] Step S12: Compare the current number of tokens between adjacent periods during the filling process of each token bucket and the current number of tokens after filling is completed with the first preset configuration information to implement the filling verification of each token bucket.

[0082] In one embodiment of the present application, the filling verification of each token bucket is implemented by comparing the current number of tokens between adjacent periods during the filling process of each token bucket and the current number of tokens after filling is completed with the first preset configuration information, including the following steps S121 to S124.

[0083] Step S121: Obtain the token number increment between each period of each token bucket according to the current token numbers between adjacent periods during the filling process of each token bucket.

[0084] Step S122: Compare the token number increment between each period of each token bucket and the current token number after filling with the first preset configuration information to obtain a comparison result.

[0085] Step S123: If the token number increment between each period of each token bucket is the same as the token bucket filling rate in the first preset configuration information, and the current token number after filling each token bucket is the same as the token bucket depth in the first preset configuration information, then the comparison result is that the filling verification of each token bucket passes;

[0086] Step S124: Otherwise, the comparison result is that the filling verification of each token bucket fails.

[0087] Specifically, if the comparison result is correct, it means that the filling verification of each token bucket of the device under test is successful. If the comparison result is incorrect, the filling verification of each token bucket of the device under test fails, indicating that there is an error in the device under test or an error in the token bucket calculation. No packets should be sent during the filling verification process so that the token bucket can always maintain a state of only increasing and not decreasing, and thus the correctness test of the token bucket filling can be completed by simply reading the token bucket periodically.

[0088] In an embodiment of the present application, performing the token bucket deduction verification on the initialized device under test and the initialized first mode model by inputting the same packet information includes the following steps S21 to S23.

[0089] Step S21: Obtain the first device under test output information according to the packet information input by the initialized device under test; the packet information includes at least one packet; the first device under test output information includes the output packets corresponding to each packet. Among them, the packet content includes, but is not limited to, the packet length and the token bucket number.

[0090] Step S22: Obtain the first mode model output information according to the same packet information input by the initialized first mode model; the first mode model output information includes the output packets corresponding to each packet.

[0091] Specifically, this application parses the message based on the input message information to obtain the parsed message information; obtains the corresponding hit token bucket according to the parsed message information and the reference model of the first mode after initialization configuration; performs bucket deduction processing according to the hit token bucket to obtain the corresponding first mode model output information; the first mode model output information includes output packets corresponding to each message; the output packet includes the message marking information of the current message and the remaining token number of the hit token bucket. For example, the corresponding hit token bucket is obtained according to the parsed token bucket number in the reference model of the first mode after initialization configuration.

[0092] Step S23: Perform packet comparison on the output packets corresponding to each message in the first device under test output information and the output packets corresponding to each message in the first mode model output information respectively to implement the bucket deduction verification of each token bucket.

[0093] In an embodiment of this application, the output packet corresponding to each message includes the message marking information of the current message and the remaining token number of the hit token bucket; performing packet comparison on the output packets corresponding to each message in the first device under test output information and the output packets corresponding to each message in the first mode model output information respectively to implement the bucket deduction verification of each token bucket includes the following steps S231 to S233.

[0094] Step S231: Perform packet comparison on the message marking information of the current message and the remaining token number of the hit token bucket in the output packet corresponding to each message in the first device under test output information and the message marking information of the current message and the remaining token number of the hit token bucket in the output packet corresponding to each message in the first mode model output information respectively, and obtain the comparison result.

[0095] Step S232: If the message marking information of the current message in the output packet corresponding to each message in the first device under test output information and the message marking information of the current message in the output packet corresponding to each message in the first mode model output information are both the same, and the remaining token number of the hit token bucket in the output packet corresponding to each message in the first device under test output information and the remaining token number of the hit token bucket in the output packet corresponding to each message in the first mode model output information are both the same, then the comparison result indicates that the bucket deduction verification of each token bucket passes.

[0096] Step S233: Otherwise, the comparison result is that the bucket deduction verification of each token bucket fails.

[0097] Specifically, after completing the initialization configuration of the device under test and the reference model of the first mode, the present application sends several messages, performs message parsing on each message, and randomly hits the corresponding token bucket based on the parsed message information. After receiving the parsed message information, the reference model of the first mode compares the number of tokens required for forwarding with the number of remaining tokens in the token bucket. If the number of remaining tokens is greater, the message is marked as forwarded; otherwise, the message is marked as discarded. In this way, the message marking information of each message and the number of remaining tokens in each token bucket can be obtained. Similarly, the device under test receives each message and obtains the message marking information of each message and the number of remaining tokens in each token bucket. The message marking information of each message output by the device under test and the number of remaining tokens in each token bucket are respectively compared with the message marking information of each message output by the reference model of the first mode and the number of remaining tokens in each token bucket. If they are consistent, it means that the comparison is correct and the bucket verification of each token bucket in the device under test is successful. Otherwise, it means that the comparison is incorrect, the bucket verification of each token bucket in the device under test fails, there is an error in the device under test or the reference model is written incorrectly.

[0098] In one embodiment of the present application, inputting the same mixed message information to the initialized device under test and the initialized second mode model respectively to perform rate verification of each token bucket includes the following steps S31 to S33.

[0099] Step S31: obtaining second device under test output information according to the initialized device under test input mixed message information; the mixed message information includes a plurality of messages of different priorities; the second device under test output information includes output packets corresponding to each message.

[0100] Step S32: obtaining second mode model output information according to the same mixed message information inputted by the initialized second mode model; the second mode model output information includes output packages corresponding to each message.

[0101] Specifically, the present application performs message parsing based on the input mixed message information to obtain the corresponding parsed message information; obtains the corresponding hit token bucket based on the parsed message information and the second mode model after initialization configuration; performs bucket deduction processing based on the hit token bucket to obtain the corresponding second mode model output information; the second mode model output information includes the output package corresponding to each message. The output package includes the message tag information of the current message and the number of remaining tokens in the hit token bucket. For example, the corresponding hit token bucket is obtained based on the reference model of the first mode after initialization configuration according to the parsed token bucket number.

[0102] Step S33: performing flow rate comparison based on the output packets corresponding to each message in the output information of the second device under test and the output packets corresponding to each message in the output information of the second mode model to implement rate verification of each token bucket.

[0103] In one implementation, the hybrid packet information includes several packets with different rates, and the hybrid packet information includes, but is not limited to, green packets, yellow packets, and / or red packets. Among them, the higher the rate of the packet, the higher the priority, and the priority order of these three types of packets is green packet > yellow packet > red packet.

[0104] In an embodiment of the present application, each packet includes a packet length and a token bucket number; the output packet corresponding to each packet includes the packet marking information of the current packet and the remaining token number of the hit token bucket; performing a flow rate comparison based on the output packets corresponding to each packet in the output information of the second device under test and the output packets corresponding to each packet in the output information of the second mode model to implement the rate verification of each token bucket includes the following steps S331 to S336.

[0105] Step S331: Perform a shunt statistics on each output stream in the output information of the second device under test to obtain the output stream rate of each output stream.

[0106] Step S332: Select the packets with the packet marking information as forwarded according to the output packets corresponding to each packet in the output information of the second device under test, and calculate and obtain the output stream rate corresponding to each output stream in each hit token bucket according to the packet length and token bucket number of the selected packets; the output stream includes the packets with the same priority in each hit token bucket; the output stream rate is the sum of the packet lengths of each packet in the current output stream divided by the total time for the device under test to process the hybrid packet information; the packet information includes forwarding and discarding.

[0107] Step S333: Select the packets with the packet marking information as forwarded according to the output packets corresponding to each packet in the output information of the second mode model, and calculate and obtain the output stream rate corresponding to each output stream in each hit token bucket according to the packet length and token bucket number of the selected packets.

[0108] Step S334: Perform a flow rate comparison on the output stream rates corresponding to each output stream in each hit token bucket calculated according to the output information of the second device under test, respectively, with the output stream rates corresponding to each output stream in each hit token bucket calculated according to the output information of the second mode model to obtain a comparison result.

[0109] Step S335: If the output stream rates corresponding to each output stream in each hit token bucket calculated according to the output information of the second device under test are the same as the output stream rates corresponding to each output stream in the same hit token bucket calculated according to the output information of the second mode model, then the comparison result is that the rate verification of each token bucket passes.

[0110] Step S336: Otherwise, the comparison result is that the rate verification of each token bucket fails.

[0111] Specifically, after the initialization configuration of the device under test and the reference model of the second mode is completed in this application, a packet sending component with controllable rate is used to send packets with different random rates to each token bucket simultaneously for a relatively long period of time. Packet parsing is performed for each packet respectively, and the corresponding token bucket is randomly hit according to the information of each parsed packet. During the process of sending packets, after the token bucket hit processing for these packets, a rate monitoring component is used to distinguish each output stream corresponding to each token bucket, and different streams must not be confused. After the sending of packets is completed, the output rates of each output stream are statistically calculated. Here, only the output packets with the packet marking information of "forward" in the output packets corresponding to each input packet are statistically calculated. The output packets here are the same as the output packets in the bucket deduction, and both include the packet marking information of the current packet and the remaining token number of the hit token bucket. After the output stream rates corresponding to each token bucket in the device under test and the second mode model are statistically calculated, the output stream rates of the two are compared. If the output rates of each output stream of the two are the same, it means that the rate limiting ability verification of this token bucket passes, that is, the rate verification of each token bucket in the device under test is successful. Otherwise, it means that the rate verification of each token bucket in the device under test fails, and there is an error in the device under test or an error in the writing of the reference model.

[0112] In one embodiment, this application uses a token bucket algorithm model of single rate, dual bucket, and three colors specified by the RFC2697 protocol to evaluate the packet traffic, and color marks the packets as the following three types according to the evaluation results: green, yellow, and red. This algorithm has two token buckets, namely bucket C and bucket E, with bucket depths of CBS (Committed Burst Size) and EBS (Excess Burst Size) respectively, and the filling rates of the two token buckets are both CIR (Committed Information Rate).

[0113] RFC 2697 is a single rate three color marker (srTCM) algorithm, mainly used for traffic supervision and quality of service (QoS) control of network traffic. This protocol classifies and marks packets through the token bucket mechanism, providing a basis for subsequent congestion management, traffic shaping, and other operations.

[0114] Figure 4 It shows the schematic diagram of single rate, dual bucket filling tokens described in the embodiment of this application. Figure 5 It shows the schematic diagram of single rate, dual bucket token deduction described in the embodiment of this application. As Figure 4-5As shown in the figure, when filling tokens in this application, tokens will be added to bucket C at the rate of CIR first. After bucket C is filled, tokens will continue to be added to bucket E until bucket E is also filled. The specific process is shown in Figure 4 When processing packets, the same three colors of packets, namely green, yellow, and red, will be received. At this time, tokens will be deducted and there cannot be a deficit. Green packets will first deduct tokens from bucket C and be marked as green. When the tokens in bucket C are insufficient, they will skip bucket C and deduct tokens from bucket E and be marked as yellow. If the tokens in bucket E are also insufficient, no tokens will be deducted and the output will be marked as red. Yellow packets will directly skip bucket C and deduct tokens from bucket E and be marked as yellow. If the tokens in bucket E are insufficient, no tokens will be deducted and the output will be marked as red. Red packets will not deduct any tokens and will be directly output marked as red. The specific process is shown in Figure 5 In addition, there is also a color-blind mode, which is equivalent to treating all input packets as green packets.

[0115] Next, taking the single-speed dual-bucket three-color algorithm as an example, the implementation of the core verification scheme of this application will be introduced step by step.

[0116] Figure 6 It shows the token bucket filling test flow chart described in the embodiment of this application. Figure 7 It shows the token bucket deduction test flow chart described in the embodiment of this application. Figure 8 It shows the rate verification flow chart described in the embodiment of this application. Figure 9 It shows the principle diagram of RFC2697 traffic policing described in the embodiment of this application.

[0117] Figure 6 It shows the token bucket filling test flow chart described in the embodiment of this application. As Figure 6 shown, this application first randomly configures the bucket depths and token bucket filling rates of bucket C and bucket E in all token buckets in the device under test according to the first preset configuration information to any reasonable values, and configures the initial token numbers in the token buckets to 0. Subsequently, all token buckets are enabled. After completing the initialization configuration and enabling the token buckets, the filling completion signal inside the device under test can be obtained. After obtaining the first filling completion pulse, the token numbers in bucket C and bucket E in all token buckets are read out and recorded in sequence through the configured communication path (the communication bus for realizing the initialization configuration) and compared with the theoretical value of the first preset configuration information. This process must be completed before obtaining the next filling cycle. When the next filling completion pulse arrives, the reading and comparison are still completed according to the above steps, and this operation is repeated multiple times until all token buckets are filled. After repeating several more cycles of operation and comparison, the verification ends.

[0118] The comparison rules for the token numbers in the token buckets are as follows in steps S41 to S43.

[0119] Step S41: If bucket C is not full, the number of tokens read from bucket E should always be 0, and the number of tokens in bucket C will increase by CIR each time it is read (there may be unit conversions). In the cycle when bucket C is filled, even if CIR is greater than the number of tokens remaining to be filled in bucket C, the excess tokens will overflow, and the number of tokens in E will still be 0.

[0120] Step S42: After bucket C is filled, bucket E starts to be filled in the next cycle, and the number of tokens in bucket E will also increase by the value of CIR each time it is read. Similarly, in the cycle when bucket E is filled, even if CIR is greater than the number of tokens remaining to be filled in bucket E, the excess tokens will overflow.

[0121] Step S43: When the tokens in both bucket C and bucket E are filled, since there is no token consumption in this verification stage and no more filling will occur, CIR continues to overflow, and all token buckets should observe that the number of tokens in bucket C and bucket E remains unchanged and is consistent with their bucket depths.

[0122] Figure 7 It shows the flowchart of the bucket deduction test described in the embodiments of the present application. As Figure 7 shown, the present application first randomly configures the bucket depths and initial token numbers of all bucket C and bucket E to any reasonable values, randomly configures the color blindness and color sensitivity modes, and configures the filling rate CIR to 0. At the same time, the same group of token buckets are also instantiated in the reference model of the verification environment, and each group is given the same initialization configuration as the DUT. After the initialization configuration is completed, several mixed-color packets are sent, randomly hitting different token buckets. The internal token bucket of the DUT will process the packets according to the logic mentioned above and output with new color markings. The reference model needs to simulate this behavior of the DUT, and continuously adjust the reference model and the DUT until the following two points are met, which can be regarded as the verification passing. One is that the number and color of the packets output by the DUT should be compared one by one with the output of the reference model and be consistent. The other is that when reading the remaining tokens in all token buckets C and bucket E at the end of the simulation, the remaining amounts of each group of token buckets of the DUT and the reference model should also be exactly the same.

[0123] The token bucket processing that the reference model needs to simulate is as follows in steps S51 to S54.

[0124] Step S51: When receiving a green packet, first determine whether the remaining tokens in bucket C can deduct the tokens required for this packet. If so, deduct the tokens from bucket C and output with a yellow marking. If the tokens in bucket C are not enough to deduct, skip bucket C and determine whether the remaining tokens in bucket E can be deducted. If so, deduct the tokens from bucket E and output with a yellow marking. Otherwise, output with a red marking.

[0125] Step S52: When a yellow message is received, directly skip the C bucket and determine whether the remaining tokens in the E bucket can still deduct the tokens required for this packet. If so, deduct the tokens from the E bucket and mark it with yellow for output; otherwise, mark it with red for output.

[0126] Step S53: When a red message is received, directly mark it with red for output.

[0127] Step S54: If the token bucket is configured in color-blind mode, it can be regarded that all input messages are green, and all received messages are processed according to Step S51.

[0128] Figure 8 It is shown as the flow chart of rate verification described in the embodiment of the present application. Figure 9 It is shown as the schematic diagram of RFC2697 traffic policing described in the embodiment of the present application. As Figure 8-9 shown, in the present application, the bucket depths and filling rates CIR of all token buckets C and E are randomly configured to any reasonable values first, and the initial number of tokens is configured to a relatively small value, and then each group of token buckets is enabled. After the initialization configuration is completed, a three-color message is sent to each group of token buckets simultaneously by using a packet-sending component with controllable rate, and the rate of each color can be random and lasts for a long time. After the packet sending is completed, the rates of various color messages input and output of each group of token buckets are respectively counted, and compared and monitored according to certain rules. If all meet the expectations, the performance test verification is completed.

[0129] The rules for rate monitoring are as follows in Steps S61 to S62.

[0130] Step S61: In color-blind mode, this algorithm can only achieve traffic monitoring of yellow and green messages. If the total rate of the input messages is less than the CIR, it is necessary to monitor that the rate of the output messages is the same as the input rate and all are green messages. If the total rate of the input messages exceeds the CIR, then the C bucket cannot be filled for a long time, and the E bucket can never be filled. At this time, it should be monitored that the output green messages have a rate of CIR, and at the same time, the output red messages have a rate of the total rate of the input messages minus the CIR, and the yellow traffic is extremely small and can be ignored.

[0131] Step S62: In the color-sensitive mode, this algorithm can only monitor the traffic of three-color packets. In this mode, the input red packets will all be converted into red. If the sum of the input green packet rate and the yellow packet rate does not exceed the CIR, then the output rates of the three-color packets are the same as the input. If the input green packet rate does not exceed the CIR but the sum of green and yellow exceeds the CIR, then the output green packet rate is the same as the input, the yellow packet rate is the CIR minus the green rate, and the rest are red. If the input green packet rate exceeds the CIR, then green packets are output with a rate of CIR, and at the same time red packets are output with a rate of the total input packet rate minus the CIR, and the yellow traffic is extremely small and can be ignored.

[0132] The token bucket verification method proposed in this application can achieve general verification for token bucket algorithms of various different protocols.

[0133] In one embodiment, if conventional verification methods are used, all token bucket configuration options are randomly configured at once, and tokens are randomly sent to each bucket. The outputs of the reference model and the DUT are then simply compared for consistency. This requires considerable effort to compile the reference model, and for each algorithm, the read and write timings of the DUT must be strictly synchronized. The filling cycle, the order in which each token bucket is filled, the timing of deductions, and the timing of deductions when filling token buckets must all be identical to those of the DUT to compile a reference model that meets the requirements. Whether the timing of deductions or filling buckets is later or earlier than that of the DUT, the real-time token counts in the token buckets maintained by the reference model during message forwarding arbitration will be inconsistent with those of the DUT, resulting in erroneous reports of packet loss for the DUT while no packet loss is reported for the reference model, or vice versa. To avoid such false positives, a significant amount of time is often required to debug the timing of the reference model to ensure its completeness. Even after debugging is complete, if the timing of a particular DUT link is modified (for example, due to RAM replacement), the timing of the reference model must also be modified simultaneously, which consumes a significant amount of time, some of which may be wasted due to solution changes. A reference model compiled in this way, even if improved, is not very reusable. Directly performing dynamic performance testing requires a significant initial simulation time to reduce the computational errors of EDA simulations. However, early verification often involves minor, easily encountered bugs that can be easily located using simple, basic use cases. Initially, a significant amount of time is spent loading waveforms to address these issues, which is inefficient. Furthermore, large waveforms make it difficult to locate the initial node where the problem occurs. These are unavoidable pain points for all token bucket algorithms, even those involved in high-volume EDA simulation testing. The core idea behind the three-step token bucket verification strategy proposed in this application is to first decompose the complex dynamic processing logic of the token bucket into independent bucket filling and bucket deleting logic. These logics are then isolated and verified separately to eliminate most bugs. Dynamic performance testing is then performed after completion, improving efficiency while ensuring the completeness of verification. The three stages of testing can not only verify different bugs, but also complement and depend on each other. The following details the specific problems that can be solved in each step of the testing process.

[0134] The bucket filling test in the first stage is the only one among the three steps that requires synchronizing the DUT signals. However, there is no need to write a reference model. We can directly use the interface to connect to the key signals inside the DUT, and then write the test expectations in the verification test cases to complete the verification. Although it is necessary to synchronize the DUT's filling completion signal, we only need to check the filled value of the token bucket between two received signals. There are not strict requirements for time nodes. As long as the test cases are written completely, even if the timing of the DUT is modified, we only need to modify the synchronized signals connected by the interface. Such changes are very small and highly beneficial for reuse. Even when switching to different projects, the reusability of such test cases is quite remarkable. In the EDA (Electronic Design Automation) field, an interface refers to an interface in the semiconductor device data acquisition standard.

[0135] The bucket emptying test in the second stage is a bit more complex and requires maintaining a reference model. However, since the interference of bucket filling is excluded and the logic of adding tokens to the token bucket is removed, there is almost no need to consider timing issues. If we directly write a reference model with complete functions, it is inevitable that the bucket filling will be earlier or later than the DUT, resulting in errors in packet arbitration by the token bucket. Although the simplified model has some missing functions, it greatly improves the code efficiency and comparison accuracy. Moreover, we can further modify the original token bucket algorithm logic and add more complex logic, such as the previously mentioned scenario where packets dropped at the previous stage do not enter the token bucket arbitration, packets authorized by the token bucket are discarded by the subsequent packet dropping logic, and special packets can skip the token bucket algorithm. These scenarios can be achieved by whether to deduct tokens and whether to mark as discarded after the reference model receives a packet, achieving complete packet-by-packet synchronization with the DUT. All in all, although this type of reference model gives up the comparison of some functions, it obtains more efficient and faster code and has strong scalability, providing fast feasibility for the reference model to integrate and verify the token bucket algorithm and other complex functions.

[0136] The dynamic rate test in the third stage is the closest to the scenario in actual applications and is also essential. After completing the tests in the first two stages, if all the discovered bugs have been eliminated one by one, it can be basically confirmed that the descriptions of the code and the design scheme are consistent. At this time, performing the third test can only further ensure that the performance of the token bucket meets the standard. Maybe no new bugs will be found, but this step is still indispensable. Because the first two steps are based on the comparison of packets from a microscopic perspective, or the comparison of the number of tokens in the token bucket, which is not enough to show that this scheme meets the requirements. Given that the token bucket algorithm is mostly used for rate control or traffic supervision, it is necessary to ensure that the verification passes in the macroscopic traffic test to increase the authenticity of the verification process and ensure that the scheme does not go wrong during actual operation. In case there are problems in the test at this stage and the performance does not meet the standard, if the problem still exists after excluding the calculation errors, it can also promote the reverse check of whether there are unreasonable points in the implementation details of the original design scheme.

[0137] The protection scope of the token bucket verification method described in the embodiments of the present application is not limited to the execution order of the steps listed in this embodiment. Any scheme realized by adding or subtracting steps of the prior art and replacing steps according to the principle of the present application is included in the protection scope of the present application.

[0138] The embodiments of the present application further provide a token bucket verification system. The token bucket verification system can implement the token bucket verification method described in the present application. However, the implementation device of the token bucket verification method described in the present application includes but is not limited to the structure of the token bucket verification system listed in this embodiment. Any structural deformation and replacement of the prior art made according to the principle of the present application are included in the protection scope of the present application.

[0139] As Figure 10 shown, this embodiment provides a token bucket verification system. The system 200 includes:

[0140] A bucket filling verification module 211, configured to perform initialization configuration on a device under test according to first preset configuration information, and perform periodic token filling on the initialized device under test to execute the bucket filling verification of each token bucket; the first preset configuration information includes the token bucket depth and the token bucket filling rate; the device under test includes at least one token bucket.

[0141] The bucket verification module 212 is configured to initialize the configuration of the device to be tested and the reference model of the first mode respectively based on the second preset configuration information, and input the same message information to the initialized device to be tested and the initialized first mode model respectively to perform bucket verification of each token bucket; the second preset configuration information includes the token bucket depth and the initial number of tokens in the token bucket; the reference model of the first mode is a model that implements the same function as the device to be tested; the first mode is a mode in which packet comparison is turned on and flow classification collection and comparison are turned off in the reference model.

[0142] The rate verification module 213 is configured to initialize the configuration of the device to be tested and the reference model of the second mode based on the third preset configuration information, and input the same mixed message information to the initialized device to be tested and the initialized second mode model to perform rate verification of each token bucket; the third preset configuration information includes the token bucket depth, the token bucket filling rate and the initial number of tokens in the token bucket; the second mode is a mode in which packet comparison is turned off and flow classification collection and comparison are turned on in the reference model.

[0143] It should be noted that the functions or operations of the bucket filling verification module 211, the bucket deduction verification module 212 and the rate verification module 213 described in the embodiment of the present disclosure correspond one-to-one to the steps in the token bucket verification method described above, so they are not repeated here.

[0144] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices or methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules / units is only a logical function division. There may be other division methods in actual implementation. For example, multiple modules or units can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules or units, which can be electrical, mechanical or other forms.

[0145] The modules / units described as separate components may or may not be physically separate, and the components displayed as modules / units may or may not be physical modules, that is, they may be located in one place or distributed across multiple network elements. Some or all of the modules / units may be selected according to actual needs to achieve the purpose of the embodiments of the present application. For example, the functional modules / units in the various embodiments of the present application may be integrated into a processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into a single module / unit.

[0146] Those skilled in the art should further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0147] Figure 11 Schematic block diagram of an electronic device provided in an embodiment of the present application. Figure 11 As shown, the electronic device 300 includes: at least one processor 311, a memory 312, at least one network interface 313 and a user interface 314. The various components in the device are coupled together through a bus system. It is understood that the bus system is used to achieve connection and communication between these components. In addition to the data bus, the bus system also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 11 Various buses are labeled as bus systems.

[0148] The user interface 314 may include a display, a keyboard, a mouse, a trackball, a click gun, keys, buttons, a touch pad or a touch screen.

[0149] It will be appreciated that the memory 312 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM) or a programmable read-only memory (PROM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memory described in the embodiments of the present invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0150] The memory 312 in the embodiment of the present invention is used to store various categories of data to support the operation of the electronic device 300. Examples of these data include: any executable program for operating on the electronic device 300, such as an operating system 3121 and an application 3122; the operating system 3121 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application 3122 can include various applications, such as a media player (Media Player), a browser (Browser), etc., for implementing various application services. The token bucket verification method provided in the embodiment of the present application can be included in the application 3122.

[0151] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 311. Processor 311 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits or software instructions in processor 311. Processor 311 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. Processor 311 can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 311 may be a microprocessor or any conventional processor. The steps of the token bucket validation method provided in the embodiments of the present invention can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium located in a memory. The processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0152] In an exemplary embodiment, the electronic device 300 may be implemented by one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), and complex programmable logic devices (CPLDs) to perform the aforementioned method.

[0153] The embodiments of the present application also provide a computer-readable storage medium. Those of ordinary skill in the art can understand that all or part of the steps in the method of implementing the above embodiments can be completed by instructing a processor through a program. The program can be stored in a computer-readable storage medium. The storage medium is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disc, and any combination thereof. The above storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrating one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)), etc.

[0154] The embodiments of the present application can also provide a computer program product, which includes one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in the embodiments of the present application are generated. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from a website, a computer, or a data center to another website, a computer, or a data center in a wired manner (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or a wireless manner (e.g., infrared, wireless, microwave, etc.).

[0155] When the computer program product is executed by a computer, the computer executes the method described in the foregoing method embodiments. The computer program product can be a software installation package. In the case where the foregoing method is required, the computer program product can be downloaded and executed on the computer.

[0156] In summary, a token bucket verification method, system, electronic device, and medium described in the present application have the following beneficial effects:

[0157] The three-step verification token bucket verification method proposed in this application disassembles the complex dynamic processing logic of the token bucket into independent token filling and token deduction logics. First, the token filling and token deduction are isolated and verified separately to eliminate most bugs. After completion, dynamic performance testing is carried out, which can improve efficiency and ensure the completeness of verification. These three stages of testing can not only verify different bugs separately, but also complement and depend on each other, and can achieve general verification for various token bucket algorithms with different protocols.

[0158] In the token filling verification stage of this application, no packets need to be sent, so that the token bucket can always maintain a state of only increasing and not decreasing. Therefore, the correctness test of the token bucket filling can be completed by continuously reading the token bucket periodically. The modification is very small, and it has high reusability for the verification of token buckets with different protocols.

[0159] In the token deduction verification stage of this application, by continuously sending packets and not allowing the device under test to fill the token bucket, the token bucket always maintains a state of only decreasing and not increasing. Then, combined with the packet output result obtained from the reference model in the first mode, the correctness test of the token bucket deduction is completed. Since there is no need to handle conflicts, this process greatly simplifies the complexity of the reference model in the first mode and reduces the labor cost required for writing.

[0160] The rate verification stage of this application is closer to the scenario in real applications. It is necessary to combine packet sending at a certain rate with the periodic filling of the token bucket. The difficulty lies in controlling the rate of input packets and monitoring the rate of the output stream without statistical errors. By monitoring that the rate of each output stream meets the expectation, the performance test of the token bucket is completed.

[0161] The descriptions of the processes or structures corresponding to the above respective drawings have their own focuses. For parts not detailed in a certain process or structure, reference can be made to the relevant descriptions of other processes or structures.

[0162] The above embodiments merely illustrate the principles and effects of this application and are not used to limit this application. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or changes completed by those with ordinary knowledge in the technical field without departing from the spirit and technical ideas disclosed in this application should still be covered by the claims of this application.

Claims

1. A token bucket verification method, characterized in that The method includes: Initializing and configuring the device under test according to first preset configuration information, and performing periodic token filling on the initialized device under test to execute the bucket filling verification of each token bucket; the first preset configuration information includes the token bucket depth and the token bucket filling rate; the device under test includes at least one token bucket; Initializing and configuring the device under test and the reference model in the first mode respectively according to second preset configuration information, and inputting the same message information into the initialized device under test and the initialized first mode model respectively to execute the bucket deduction verification of each token bucket; the second preset configuration information includes the token bucket depth and the initial number of tokens in the token bucket; the reference model is a model that realizes the same function as the device under test; the first mode is a mode in which packet comparison is turned on and flow classification collection and comparison are turned off in the reference model; Initializing and configuring the device under test and the reference model in the second mode respectively according to third preset configuration information, and inputting the same mixed message information into the initialized device under test and the initialized second mode model respectively to execute the rate verification of each token bucket; the third preset configuration information includes the token bucket depth, the token bucket filling rate, and the initial number of tokens in the token bucket; the second mode is a mode in which packet comparison is turned off and flow classification collection and comparison are turned on in the reference model.

2. The token bucket verification method according to claim 1, wherein Performing periodic token filling on the initialized device under test to execute the bucket filling verification of each token bucket includes: Performing periodic token filling on the initialized device under test to obtain filling token information; the filling token information includes the current number of tokens between adjacent periods during the filling process of each token bucket and the current number of tokens after filling is completed; Comparing the current number of tokens between adjacent periods during the filling process of each token bucket and the current number of tokens after filling is completed with the first preset configuration information to implement the bucket filling verification of each token bucket.

3. The token bucket verification method according to claim 2, wherein Comparing the current number of tokens between adjacent periods during the filling process of each token bucket and the current number of tokens after filling is completed with the first preset configuration information to implement the bucket filling verification of each token bucket includes: Obtaining the token increment of each token bucket per period according to the current number of tokens between adjacent periods during the filling process of each token bucket; Comparing the token increment of each token bucket per period and the current number of tokens after filling is completed with the first preset configuration information to obtain a comparison result; If the token increment of each token bucket per period is the same as the token bucket filling rate in the first preset configuration information, and the current number of tokens after filling of each token bucket is the same as the token bucket depth in the first preset configuration information, then the comparison result is that the bucket filling verification of each token bucket passes; Otherwise, the comparison result is that the bucket filling verification of each token bucket fails.

4. The token bucket verification method according to claim 1, wherein Inputting the same message information into the initialized device under test and the initialized first mode model respectively to execute the bucket deduction verification of each token bucket includes: Obtain the first output information of the device under test according to the input message information of the device under test after initialization; the message information includes at least one message; the first output information of the device under test includes output packets corresponding to each message. Obtain the first model output information according to the same message information input into the first mode model after initialization; the first model output information includes output packets corresponding to each message. Perform packet comparison on the output packets corresponding to each message in the first output information of the device under test and the output packets corresponding to each message in the first model output information respectively to implement the token bucket deduction verification for each token bucket.

5. The token bucket verification method according to claim 4, wherein The output packets corresponding to each message include the message marking information of the current message and the remaining token number of the hit token bucket; performing packet comparison on the output packets corresponding to each message in the first output information of the device under test and the output packets corresponding to each message in the first model output information respectively to implement the token bucket deduction verification for each token bucket includes: Perform packet comparison on the message marking information of the current message and the remaining token number of the hit token bucket in the output packets corresponding to each message in the first output information of the device under test with the message marking information of the current message and the remaining token number of the hit token bucket in the output packets corresponding to each message in the first model output information respectively, and obtain the comparison result. If the message marking information of the current message in the output packets corresponding to each message in the first output information of the device under test and the message marking information of the current message in the output packets corresponding to each message in the first model output information are the same, and the remaining token number of the hit token bucket in the output packets corresponding to each message in the first output information of the device under test and the remaining token number of the hit token bucket in the output packets corresponding to each message in the first model output information are the same, then the comparison result indicates that the token bucket deduction verification for each token bucket passes. Otherwise, the comparison result is that the token bucket deduction verification for each token bucket fails.

6. The token bucket verification method according to claim 1, wherein Respectively input the same mixed message information into the device under test after initialization and the second mode model after initialization to perform the rate verification for each token bucket, including: Obtain the second output information of the device under test according to the input mixed message information of the device under test after initialization; the mixed message information includes several messages with different priorities; the second output information of the device under test includes output packets corresponding to each message. Obtain the second model output information according to the same mixed message information input into the second mode model after initialization; the second model output information includes output packets corresponding to each message. Perform flow rate comparison on the output packets corresponding to each message in the second output information of the device under test and the output packets corresponding to each message in the second model output information to implement the rate verification for each token bucket.

7. The token bucket verification method according to claim 6, wherein Each message includes a message length and a token bucket number; the output packets corresponding to each message include the message marking information of the current message and the remaining token number of the hit token bucket; performing flow rate comparison on the output packets corresponding to each message in the second output information of the device under test and the output packets corresponding to each message in the second model output information to implement the rate verification for each token bucket includes: Select the packets with the packet marking information as forwarded according to the output packets corresponding to each packet in the output information of the second device under test, and calculate and obtain the output stream rate corresponding to each output stream in each hit token bucket according to the packet length and token bucket number of the selected packets; the output streams include the packets with the same priority in each hit token bucket; the output stream rate is the sum of the packet lengths of each packet in the current output stream divided by the total time for the device under test to process the mixed packet information; the packet information includes forwarding and discarding. Select the packets with the packet marking information as forwarded according to the output packets corresponding to each packet in the output information of the second mode model, and calculate and obtain the output stream rate corresponding to each output stream in each hit token bucket according to the packet length and token bucket number of the selected packets. Compare the output stream rates corresponding to each output stream in each hit token bucket calculated according to the output information of the second device under test with the output stream rates corresponding to each output stream in each hit token bucket calculated according to the output information of the second mode model, and obtain the comparison result. If the output stream rates corresponding to each output stream in each hit token bucket calculated according to the output information of the second device under test are the same as the output stream rates corresponding to each output stream in the same hit token bucket calculated according to the output information of the second mode model, then the comparison result is that the rate verification of each token bucket passes. Otherwise, the comparison result is that the rate verification of each token bucket fails.

8. A token bucket verification system, characterized in that The system includes: A bucket filling verification module, configured to initialize and configure the device under test according to the first preset configuration information, and perform periodic token filling on the initialized device under test to perform the bucket filling verification of each token bucket; the first preset configuration information includes the token bucket depth and the token bucket filling rate; the device under test includes at least one token bucket. A bucket deduction verification module, configured to initialize and configure the device under test and the reference model of the first mode respectively based on the second preset configuration information, and input the same packet information into the initialized device under test and the initialized first mode model respectively to perform the bucket deduction verification of each token bucket; the second preset configuration information includes the token bucket depth and the initial number of tokens in the token bucket; the reference model of the first mode is a model that realizes the same function as the device under test; the first mode is a mode in which packet comparison is turned on, flow classification collection and comparison are turned off in the reference model. A rate verification module, configured to initialize and configure the device under test and the reference model of the second mode respectively based on the third preset configuration information, and input the same mixed packet information into the initialized device under test and the initialized second mode model respectively to perform the rate verification of each token bucket; the third preset configuration information includes the token bucket depth, the token bucket filling rate, and the initial number of tokens in the token bucket; the second mode is a mode in which packet comparison is turned off, flow classification collection and comparison are turned on in the reference model.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory; wherein, The memory is used to store a computer program. The processor is used to execute the computer program stored in the memory, so that the electronic device executes the token bucket verification method described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the electronic device, it implements the token bucket verification method described in any one of claims 1 to 7.

Images