A token bucket verification method and system, electronic device and medium

Abstract

The application provides a token bucket verification method, system, electronic equipment and medium. The method comprises: initializing and configuring a to-be-tested device according to first preset configuration information, periodically filling tokens in the to-be-tested device to perform token filling verification of each token bucket; initializing and configuring the to-be-tested device and a reference model in a first mode based on second preset configuration information, inputting the same message information into the initialized to-be-tested device and the initialized reference model in the first mode to perform token deduction verification of each token bucket; and initializing and configuring the to-be-tested device and a reference model in a second mode based on third preset configuration information, inputting the same mixed message information into the initialized to-be-tested device and the initialized reference model in the second mode to perform rate verification of each token bucket. The token bucket verification is performed in three steps, and general verification can be realized for token bucket algorithms of various different protocols.

Description

Technical Field

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

[0002] The token bucket algorithm is a commonly used algorithm in the QoS (Quality of Service) function of switches (the algorithm flow is as follows). Figure 1 As shown (indicated), it 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 depth: the system adds tokens to it at a fixed rate, up to a depth matching the bucket's depth; any excess tokens are discarded. Each token represents a certain amount of permission to pass through the flow. Whenever a packet enters the token bucket for arbitration, its forwarding permission is evaluated. If there are enough tokens in the bucket, the packet passing through will consume the tokens corresponding to its forwarding permission and be granted permission to pass. Conversely, if there are insufficient tokens, the packet will be discarded or subjected to backpressure to restrict forwarding. From the above information, it can be seen that the token filling rate is the maximum rate at which a flow is allowed to pass through the token bucket, and the bucket depth is the promised maximum burst value. In practical applications, multiple token buckets often need to be maintained simultaneously; therefore, in design and implementation, information on token buckets with the same function is generally stored in the same RAM. After enabling the token bucket function, the system reads the token bucket information from RAM, calculates the new fill value, and writes it back to RAM. The system periodically traverses all addresses, refreshing each token bucket sequentially. When a message is received, the system parses the corresponding token bucket address, reads the token bucket information from the corresponding address in RAM, calculates the deducted value, and writes it back to RAM. This process reads and writes the corresponding addresses in a fixed timing sequence according to the order in which the messages are received, completing the token bucket refresh. Note that during RAM read / write operations, filling and deduction only refresh the token count in the token bucket and do not modify the configuration information. The token bucket filling rate and bucket depth are only affected by the configuration path. From the above information, it can be seen that verifying the token bucket algorithm involves not only verifying the built-in addition and subtraction logic for single or multiple token buckets, but also, and perhaps more importantly, verifying how to handle read / write conflicts when adding and deducting token buckets.

[0003] So how should the token bucket algorithm be verified? When first exposed to verification, general verification personnel always pursue consistent input and output comparison, that is, input various random stimuli combined with different configurations; if the DUT (Device Under Test, DUT, device under test) output result can always meet the expectation (consistent with the reference model) and be considered as passing the verification. Although this idea is reasonable, if it is directly applied to the test of the token bucket algorithm, it will bring two problems. On the one hand, if the reference model is to be consistent with the DUT in the processing of each packet, it is necessary to completely simulate the increase and decrease of all token buckets, align the timing with the DUT, which is a complex process and too dependent on the time node of the DUT adding and deducting tokens. On the other hand, even if the correctness of each packet processing is guaranteed, can it be said that the design of the token bucket algorithm meets the expected effect? The answer is definitely no. Because whether it is interface rate limiting or flow regulation, etc., its essence is the macro control of classified flow, if only from the micro perspective, then only half of the work is done. What if we change our approach and start with macro monitoring, verifying whether the output flow rate meets the expected value? This indeed directly touches the ultimate goal of verification, but in the actual operation process, two difficult problems will also be encountered. First of all, if the DUT has a bug, such a verification method can only monitor the flow rate that does not meet the expected value for a long period of time, and cannot accurately locate the time node when the bug first appears, thus leading to low efficiency in finding and repairing bugs. Secondly, if the module contains other functions besides the token bucket algorithm, such as the pre-stage packet loss not entering the token bucket arbitration, the token bucket authorized packet being discarded by the post-stage packet loss logic, or supporting some special packets to skip the token bucket algorithm processing and pass directly, the more these functions are mixed, the more difficult it is to predict the final output flow rate, increasing the testing difficulty. However, if we do not test the mixed scene, we may miss some bugs. Therefore, the direct macro monitoring test method also has its limitations. SUMMARY

[0004] The present application provides a token bucket verification method, system, electronic device and medium, which is 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 a first aspect, a token bucket verification method is provided. The method comprises: performing initialization configuration on a to-be-tested device according to first preset configuration information, and performing periodic token filling on the initialized to-be-tested device 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 to-be-tested device comprises at least one token bucket; performing initialization configuration on the to-be-tested device and a reference model in a first mode based on second preset configuration information, and inputting the same packet information into the initialized to-be-tested device and the initialized reference model in the first mode to perform bucket deduction verification of each token bucket; the second preset configuration information comprises a token bucket depth and a token bucket initial token number; the reference model is a model having the same function as the to-be-tested device; 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; performing initialization configuration on the to-be-tested device and the reference model in a second mode based on third preset configuration information, and inputting the same mixed packet information into the initialized to-be-tested device and the initialized reference model in the second mode to perform rate verification of each token bucket; the third preset configuration information comprises a token bucket depth, a token bucket filling rate and a token bucket initial token number; 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.

[0006] In an implementation form of the first aspect, the periodic token filling on the initialized to-be-tested device to perform bucket filling verification of each token bucket comprises: performing periodic token filling on the initialized to-be-tested device to obtain filling token information; the filling token information comprises current token numbers of each token bucket between adjacent periods in the filling process and current token numbers after the filling is completed; and the current token numbers of each token bucket between adjacent periods in the filling process and the current token numbers after the filling is completed are compared with the first preset configuration information to implement the bucket filling verification of each token bucket.

[0007] In an implementation form of the first aspect, the comparison of the current token numbers of each token bucket between adjacent periods in the filling process and the current token numbers after the filling is completed with the first preset configuration information to implement the bucket filling verification of each token bucket comprises: obtaining a token number increment of each token bucket in each period according to the current token numbers of each token bucket between adjacent periods in the filling process; comparing the token number increment of each token bucket in each period and the current token numbers after the filling is completed with the first preset configuration information to obtain a comparison result; if the token number increment of each token bucket in each period is the same as the token bucket filling rate in the first preset configuration information, and the current token numbers of each token bucket after the filling is completed are the same as the token bucket depth in the first preset configuration information, the comparison result is that the bucket filling verification of each token bucket is passed; otherwise, the comparison result is that the bucket filling verification of each token bucket is not passed.

[0008] In an implementation form of the first aspect, the inputting the same packet information to the initialized DUT and the initialized reference model of the first mode respectively to perform the token-bucket verification of each token bucket comprises: obtaining first DUT output information according to the initialized DUT inputting the packet information; the packet information comprises at least one packet; the first DUT output information comprises an output packet corresponding to each packet; obtaining first reference model of the first mode output information according to the initialized reference model of the first mode inputting the same packet information; the first reference model of the first mode output information comprises an output packet corresponding to each packet; and performing packet comparison according to the output packet corresponding to each packet in the first DUT output information and the output packet corresponding to each packet in the first reference model of the first mode output information to realize the token-bucket verification of each token bucket.

[0009] In an implementation form of the first aspect, the output packet corresponding to each packet comprises packet mark information of a current packet and a remaining token number of a hit token bucket; and the packet comparison according to the output packet corresponding to each packet in the first DUT output information and the output packet corresponding to each packet in the first reference model of the first mode output information to realize the token-bucket verification of each token bucket comprises: performing packet comparison according to the packet mark information of the current packet and the remaining token number of the hit token bucket in the output packet corresponding to each packet in the first DUT output information and the packet mark information of the current packet and the remaining token number of the hit token bucket in the output packet corresponding to each packet in the first reference model of the first mode output information, to obtain a comparison result; if the packet mark information of the current packet in the output packet corresponding to each packet in the first DUT output information and the packet mark information of the current packet in the output packet corresponding to each packet in the first reference model of the first mode output information are the same, and the remaining token number of the hit token bucket in the output packet corresponding to each packet in the first DUT output information and the remaining token number of the hit token bucket in the output packet corresponding to each packet in the first reference model of the first mode output information are the same, the comparison result indicates that the token-bucket verification of each token bucket is passed; otherwise, the comparison result indicates that the token-bucket verification of each token bucket is failed.

[0010] In an implementation form of the first aspect, the inputting the same mixed packet information to the initialized to-be-tested device and the initialized second-mode reference model respectively to perform the rate verification of each token bucket comprises: obtaining second to-be-tested device output information according to the input of the initialized to-be-tested device into the mixed packet information; the mixed packet information comprises a plurality of packets of different priorities; the second to-be-tested device output information comprises output packets corresponding to each packet; obtaining second-mode reference model output information according to the input of the initialized second-mode reference model into the same mixed packet information; the second-mode reference model output information comprises output packets corresponding to each packet; and performing flow rate comparison between the output packets corresponding to each packet in the second to-be-tested device output information and the output packets corresponding to each packet in the second-mode reference model output information to achieve the rate verification of each token bucket.

[0011] In an implementation form of the first aspect, each packet comprises a packet length and a token bucket number; the output packet corresponding to each packet comprises packet marking information of a current packet and a remaining token number of a hit token bucket; and the flow rate comparison between the output packets corresponding to each packet in the second to-be-tested device output information and the output packets corresponding to each packet in the second-mode reference model output information to achieve the rate verification of each token bucket comprises: selecting packet marking information as a forwarded packet according to the output packets corresponding to each packet in the second to-be-tested device output information, and calculating and obtaining output flow rates corresponding to each output flow in each hit token bucket according to the packet length and the token bucket number of the selected packet; the output flow comprises packets of the same priority in each hit token bucket; and the output flow rate is a sum of packet lengths of each packet in a current output flow divided by a total time for the to-be-tested device to process the mixed packet information; the packet information comprises forwarding and discarding; selecting packet marking information as a forwarded packet according to the output packets corresponding to each packet in the second-mode reference model output information, and calculating and obtaining output flow rates corresponding to each output flow in each hit token bucket according to the packet length and the token bucket number of the selected packet; comparing the output flow rates corresponding to each output flow in each hit token bucket calculated and obtained according to the second to-be-tested device output information with the output flow rates corresponding to each output flow in each hit token bucket calculated and obtained according to the second-mode reference model output information respectively to obtain a comparison result; and if the output flow rates corresponding to each output flow in each hit token bucket calculated and obtained according to the second to-be-tested device output information are the same as the output flow rates corresponding to each output flow in the same hit token bucket calculated and obtained according to the second-mode reference model output information, 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 not passed.

[0012] In a second aspect, the application provides a token bucket verification system, which comprises: a bucket filling verification module configured to perform initialization configuration on a to-be-tested device according to first preset configuration information, and to perform periodic filling of tokens of each token bucket to perform bucket filling verification according to the initialized to-be-tested device; the first preset configuration information comprises a token bucket depth and a token bucket filling rate; the to-be-tested device comprises at least one token bucket; a bucket deduction verification module configured to perform initialization configuration on the to-be-tested device and a reference model of a first mode respectively based on second preset configuration information, and to input the same packet information to the initialized to-be-tested device and the initialized reference model of the first mode of reference 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 initial token number; the reference model of the first mode is a model having the same function as the to-be-tested device; 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 perform initialization configuration on the to-be-tested device and a reference model of a second mode respectively based on third preset configuration information, and to input the same mixed packet information to the initialized to-be-tested device and the initialized reference model of the second mode to perform rate verification of each token bucket; the third preset configuration information comprises a token bucket depth, a token bucket filling rate and a token bucket initial token number; 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.

[0013] In a third aspect, the application provides an electronic device, which comprises: 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 application provides a computer readable storage medium, which stores a computer program, and the program is executed by an electronic device to implement the token bucket verification method as described above.

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

[0016] The three-step verification token bucket verification method provided by the application can improve efficiency and ensure the completeness of verification by first decomposing the complex dynamic processing logic of the token bucket into independent bucket filling and bucket deduction logic, isolating the bucket filling and bucket deduction, and performing verification to exclude most bugs. Dynamic performance testing is performed after completion, which can improve efficiency and ensure the completeness of verification. The three stages of testing can verify different bugs respectively, and are complementary and dependent on each other. The token bucket algorithm of various different protocols can be verified universally.

[0017] The application does not need to send any message in the bucket filling verification stage, so that the token bucket can always maintain the state of only adding and not reducing, thereby only needs to constantly read the token bucket according to the period to complete the correctness test of the token bucket filling, and the change is very small, and the token bucket verification reuse is high for different protocols.

[0018] The application always sends a packet in the bucket deduction verification stage, and does not allow the device under test to fill the token bucket, so that the token bucket always maintains the state of only reducing and not adding, and then the correctness test of the token bucket deduction is completed in combination with the packet output result obtained by the reference model of the first mode. Since no conflict processing is needed, the complexity of the reference model of the first mode is greatly simplified, and the human cost required for writing is reduced.

[0019] The application is close to the scene in the real application in the rate verification stage, and needs to combine the packet sending according to a certain rate and the periodic filling of the token bucket. The difficulty lies in that the rate of the input message and the rate of the output flow cannot have statistical errors. By monitoring the rate of each flow output as expected, the performance test of the token bucket is completed. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 A working principle diagram of the token bucket described in the embodiments of the application is shown.

[0021] Figure 2 An application scenario diagram of the token bucket verification method described in the embodiments of the application is shown.

[0022] Figure 3 A flow diagram of the token bucket verification method described in the embodiments of the application is shown.

[0023] Figure 4 A single-speed double-bucket filling token principle diagram described in the embodiments of the application is shown.

[0024] Figure 5 A single-speed double-bucket deduction token principle diagram described in the embodiments of the application is shown.

[0025] Figure 6 A filling test flowchart described in the embodiments of the application is shown.

[0026] Figure 7 A bucket deduction test flowchart described in the embodiments of the application is shown.

[0027] Figure 8 A rate verification flowchart described in the embodiments of the application is shown.

[0028] Figure 9 An RFC2697 flow monitoring principle diagram described in the embodiments of the application is shown.

[0029] Figure 10 A structural schematic diagram of a token bucket verification system is shown.

[0030] Figure 11 A structural schematic diagram of an electronic device is shown.

[0031] Element number explanation

[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] S1-S3 steps DETAILED DESCRIPTION

[0051] The embodiments of the present application will be described in detail hereinafter with specific reference being made to the figures. The advantages and effects of the present application can be easily understood by those skilled in the art from the disclosure of the present specification. The present application can also be implemented or applied by other different embodiments, and the details in the present specification can be modified or changed based on different views and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0052] It should be noted that the diagrams provided in the following embodiments only illustrate the basic concepts of the present application in a schematic manner, and only show the components related to the present application in the diagrams, not drawn according to the number, shape and size of the components in actual implementation. The actual implementation of each component may be a random change in type, number and proportion, and the component layout pattern may be more complex.

[0053] The following embodiments of the present application provide a token bucket verification method and system, electronic equipment and medium, which solve the problem that the existing token bucket verification method is difficult to simultaneously apply to the verification of token bucket algorithms of different protocols.

[0054] The embodiments of the present application provide a token bucket verification method, which is applied to electronic equipment, and the electronic equipment can be a server, a personal computer (PC), a tablet computer, a smart phone, a personal digital assistant (PDA) and the like, which has a logical computing function and can test token algorithms according to different token conditions, thereby effectively improving the effectiveness and accuracy of token testing.

[0055] Please refer to Figure 2 , Figure 2 A block diagram of an electronic device provided by the embodiments of the present application is shown. The electronic device 100 can 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 skilled in the art can understand that Figure 2 The structure shown is only schematic, which does not limit the structure of the electronic device 100. For example, the electronic device 100 can also include more or less components than those shown in Figure 2 , or have a different configuration from Figure 2 .

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

[0057] The processor 113 described above may be an integrated circuit chip with signal processing capabilities. The 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, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The peripheral interface 114 described above 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 in a single chip. In other instances, they may be implemented by separate chips. The input / output unit 115 described above is used to provide user input data. The input / output unit 115 may be, but is not limited to, a mouse and a keyboard, etc. The aforementioned display unit 116 provides an interactive interface (e.g., a user interface) between the electronic device 100 and the user, or displays image data for the user's reference. In this embodiment, the display unit can be a liquid crystal display (LCD) or a touch display. If it is a touch display, it can be a capacitive touchscreen or a resistive touchscreen that supports single-point and multi-point touch operations. Supporting single-point and multi-point touch operations means that the touch display can sense touch operations generated simultaneously from one or more locations on the touch display and pass the sensed touch operations to the processor for calculation and processing. In this embodiment, 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 various steps in the token bucket verification methods provided in the embodiments of this application. The implementation process of the token bucket verification method is described in detail below through several embodiments.

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

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

[0061] Step S1, initializing and configuring the device under test according to first preset configuration information, and performing periodic token filling to execute the filling verification of each token bucket according to the initialized device under test; the first preset configuration information includes token bucket depth and 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 an implementation manner, initializing and configuring the device under test (DUT) according to the first preset configuration information includes: 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 be any reasonable value according to the token bucket protocol type (any reasonable value is a condition value satisfying that the initial token number of the token bucket is less than or equal to the token bucket depth), and configuring the initial token number of each token bucket to be 0, and enabling all token buckets after the configuration is completed. Wherein, the token bucket depth and the token bucket filling rate should not be too different to cause too long filling time, and the token bucket enabling should be configured after the token bucket depth and the token bucket filling rate and other token bucket information are configured.

[0063] In an implementation, the periodic filling of tokens to the initialized to-be-tested device for the bucket filling verification of each token bucket includes: periodically filling tokens to the initialized to-be-tested device, reading the current token number of each token bucket between the first filling period and the non-filling in 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 according to the current token number of each token bucket read between the first filling period and the non-filling in 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 both are consistent, it indicates that the comparison is correct, the bucket filling verification of each token bucket of the to-be-tested device in the first filling period is successful, otherwise, it indicates that the comparison is incorrect, and the to-be-tested device has an error or the token bucket calculation is incorrect. Because the initialized to-be-tested device is periodically filled with tokens, only when the token number increment of each token bucket in each filling period is equal to the filling rate, and the current token number of each token bucket after the filling is completed is always consistent with the token bucket depth, it indicates that the bucket filling verification of each token bucket of the to-be-tested device is successful, otherwise, it indicates that the bucket filling verification of each token bucket of the to-be-tested device fails. Therefore, the current token number of each token bucket needs to be read between two filling periods in the continuous filling process, and the current token number of each token bucket needs to be read for a period of time after the filling is completed, whether the token number increment of each token bucket is equal to the filling rate is compared according to the current token number of each token bucket read between two filling periods in the filling process, and whether the current token number of each token bucket is always consistent with the token bucket depth is compared, if both are consistent in each filling period, it indicates that the comparison is correct, the bucket filling verification of each token bucket of the to-be-tested device is successful, otherwise, it indicates that the comparison is incorrect, the bucket filling verification of each token bucket of the to-be-tested device fails, and the to-be-tested device has an error or the token bucket calculation is incorrect.

[0064] It should be noted that the bucket filling verification in step S1 of the present application must not send any message, so that the token bucket can always remain in the state of only adding and not reducing, so that the correctness test of the token bucket filling can be completed by continuously reading the token bucket according to the period.

[0065] In step S2, the to-be-tested device and the reference model of the first mode are respectively initialized and configured based on second preset configuration information, and the same message information is input to the initialized to-be-tested device and the initialized reference model of the first mode to perform the bucket deduction verification of each token bucket; the second preset configuration information includes the token bucket depth and the initial token number of the token bucket; the reference model is a model having the same function as the to-be-tested device; and the first mode is a mode in which the packet comparison is turned on, the flow classification collection and comparison are turned off in the reference model.

[0066] In an implementation, the initialization configuration of the to-be-tested device and the reference model of the first mode based on the second preset configuration information respectively comprises: configuring the token bucket depth and the initial token number of each token bucket in the token bucket model of the to-be-tested device to be any reasonable value (any reasonable value is a value satisfying the condition that the initial token number is less than or equal to the token bucket depth), and configuring the token bucket filling rate of each token bucket to be 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 configured with the same configuration as the to-be-tested device. The reference model is a model having the same function as the to-be-tested device; 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. In the reference model of the first mode, only packet comparison is performed, and flow comparison is not performed.

[0067] In an implementation, the initialization configuration of the to-be-tested device and the reference model of the first mode based on the second preset configuration information respectively comprises: configuring the token bucket depth and the initial token number of each token bucket in the token bucket model of the to-be-tested device to be any reasonable value (any reasonable value is a value satisfying the condition that the initial token number is less than or equal to the token bucket depth), and configuring the token bucket filling rate of each token bucket to be 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 configured with the same configuration as the to-be-tested device. The reference model is a model having the same function as the to-be-tested device; 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. In the reference model of the first mode, only packet comparison is performed, and flow comparison is not performed.

[0068] In the present embodiment, in the bucket verification process in step S2, the packet input of the device under test and the reference model of the first mode is one packet at a time, so that one output is obtained respectively, that is, one packet is input to the device under test, and one output packet is obtained correspondingly, one packet is input to the reference model of the first mode, and one output packet is obtained correspondingly, and the two output packets are compared to perform the bucket verification of each token bucket, that is, the packet comparison mode. The output packet includes the packet mark information of the current packet and the remaining token number of the hit token bucket, that is, the packet mark information in the two output packets is the same, and the remaining token number of the hit 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 packet content includes a packet length and a token bucket number, wherein the token bucket number is used to select the token bucket hit by the current packet. The packet length is used to consume tokens, and the longer the packet length, the more forwarding rights the current packet needs in the hit token bucket. However, the packet content is not limited to the packet length and the token bucket number, and the present application is not limited thereto.

[0070] It should be noted that the processing method of the bucket verification in step S2 and the processing method of the bucket filling verification in the previous stage are just opposite, and it is necessary to continuously send packets and not to fill the token bucket of the device under test, so that the token bucket always maintains a state of only decreasing but not increasing, and then the packet output result obtained by the reference model of the first mode is combined to complete the correctness test of the token bucket. Since no conflict processing is required, this process greatly simplifies the complexity of the reference model of the first mode and reduces the human cost required for writing.

[0071] Step S3, based on third preset configuration information, respectively initializing and configuring the device under test and the reference model of the second mode, and inputting the same mixed packet information to the initialized device under test and the initialized reference model of the second mode to perform the rate verification of each token bucket; the third preset configuration information includes a token bucket depth, a token bucket filling rate and an initial token number of the token bucket; the second mode is a mode in which packet comparison is closed, flow classification collection and comparison are opened in the reference model.

[0072] In an implementation, the initialization configuration of the to-be-tested device and the reference model of the second mode based on the third preset configuration information respectively comprises: configuring the token bucket depth and the token bucket filling rate of each token bucket in the token bucket model of the to-be-tested device randomly as any reasonable value (any reasonable value is a value satisfying 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 as a smaller value, and enabling all token buckets after the configuration is completed. The token bucket depth should not be too small to cause insufficient ability to deal with burst traffic, nor should it be too large to cause excessive instantaneous traffic. In addition to configuring the 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 enabling is also configured. At the same time, the reference model of the second mode of the verification environment is configured with the same configuration as the to-be-tested device. The reference model of the second mode has the same number of token buckets as the to-be-tested device. The second mode is a mode in which the packet comparison is closed, the flow classification collection and comparison are opened 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 an implementation, the rate verification of each token bucket by inputting the same mixed message information to the initialized to-be-tested device and the initialized reference model of the second mode respectively comprises: after the initialization configuration of the to-be-tested device and the reference model of the second mode is completed, the packet sending assembly with controllable rate is used to send different random rate messages to each token bucket at the same time for a long period of time, wherein the messages with different rates represent different priorities of the messages, and the higher the rate, the higher the priority. In the process of sending packets, after the token bucket hit processing of the messages is performed, the rate monitoring assembly is used to distinguish each output flow corresponding to each token bucket, and different flows should not be confused, and the output rate of each output flow is counted after the packet sending is completed. Here, only the output packets in which the message tag information of each input message is forwarded are counted. The output packets here are the same as the output packets in the token bucket, and both include the message tag information of the current message and the remaining token number of the hit token bucket. After the rate of each output flow corresponding to each token bucket in the to-be-tested device and the reference model of the second mode is counted, the rates of the output flows of the two are compared. If the output rates of the output flows of the two are the same, it means that the rate verification of each token bucket in the to-be-tested device is successful, otherwise it means that the rate verification of each token bucket in the to-be-tested device fails, and the to-be-tested device has an error or the reference model is written incorrectly.

[0074] It should be noted that the rate verification of step S3 of the present application is close to the scene in the real application, and the packet sending at a certain rate and the periodic filling of the token bucket need to be combined. The difficulty lies in that the control of the input message rate and the monitoring of the output flow rate cannot have statistical errors. By monitoring the rate of each output flow to meet the expectation, the performance test of the token bucket is completed.

[0075] Specifically, the present application proposes a new three-step verification method, which divides the token bucket verification into three steps of filling bucket verification, deducting bucket verification and rate verification. For various token bucket algorithms of different protocols, universal verification can be achieved.

[0076] In an embodiment, the present application verifies whether the token bucket filling process is correct. First, the token bucket depth and the token bucket filling rate are randomly configured as any reasonable value, and the initial token number of the token bucket is configured as 0; after the configuration is completed, all token buckets are enabled. Since the token buckets are added according to a fixed period, each token bucket is read and written in turn. Therefore, after the initialization configuration is completed, the filling period of the device under test needs to be synchronized immediately (synchronization can be achieved through the internal signal of the device under test). After each time the filling completion signal of the device under test is monitored, the token number in each token bucket is read out in turn through the configuration path and recorded before the next filling period arrives. The operation is repeated according to the period. If the recorded token increment is consistent with the configured filling rate after each filling period is completed, and the token number after filling remains consistent with the bucket depth in the subsequent period, it means that the verification is passed. The verification in this stage must not send any message, so that the token bucket can always remain in the state of only adding and not reducing, thereby only reading the token bucket periodically can complete the correctness test of the token bucket filling.

[0077] In an embodiment, the application verifies whether the token bucket depletion process is correct. This step needs the help of the reference model of the first mode to complete the verification. First, all token buckets are still enabled, and the token bucket depth and the initial token number of the token bucket are randomly configured as any reasonable value (the initial token number of the token bucket can 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 are given the same configuration and initial token number as the device under test. After completing the initialization configuration, send a number of messages, randomly hit different token buckets, and the reference model of the first mode will compare the number of tokens consumed and the remaining token number of the token bucket when receiving the message. If the remaining token number is more, mark the message as forwarded, otherwise mark the message 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 have deductions and will not be filled. Therefore, there is no need to consider the impact of the timing of the filling, and only the corresponding token buckets need to be processed in the order of receiving the message. Even if the time node of the depletion may not be completely consistent, it can be guaranteed that the remaining token number of the token bucket in the reference model of the first mode and the device under test is consistent at each time of processing the message. If the discard and pass marks of the messages output by the reference model of the first mode and the device under test are consistent, and the remaining values of the token buckets in the device under test and the reference model of the first mode are consistent at the end of the simulation, it means that the verification is passed. Since there is no need to do conflict processing, this process greatly simplifies the complexity of the reference model of the first mode and reduces the human cost required for writing. The verification method of this stage is just the opposite of the previous stage of verification. It must be through a continuous packet sending and not allowing the device under test to fill to keep the token bucket in a state of only decreasing but not increasing, and then combined with the message output result obtained by the reference model of the first mode to complete the correctness test of the token bucket depletion.

[0078] In an embodiment, the application verifies whether the rate-limiting capability 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 value, and configure the initial token number of the token bucket to a small value. (Note: In actual applications, traffic testing is usually performed after the token bucket is filled, but because the EDA (Electronic Design Automation) simulation time is short, to avoid the statistical error caused by the initial token number of the token bucket being too large to release more traffic, the initial token number of the token bucket is usually configured to a small value before testing). After the above initialization configuration is completed on the device under test and the reference model of the second mode, use the controllable rate packet sending component to send different random rate flows to each token bucket at the same time for a long period of time. During the packet sending process, the rate monitoring component needs to distinguish the output flow corresponding to each input flow, and should not mix different flows, and the output rate of each flow is counted after the packet sending is completed. If it is found through comparison that the output rate of each output flow corresponding to the device under test and the output rate of each output flow corresponding to the reference model of the second mode are consistent, it means that the rate-limiting capability verification of the token bucket is passed. The verification in the last stage is closer to the scene in the actual application, and needs to combine the packet sending at a certain rate and the periodic filling of the token bucket. The difficulty lies in that the control of the rate of the input flow and the monitoring of the rate of the output flow cannot have statistical errors. By monitoring the rate of each output flow, the performance test of the token bucket is completed.

[0079] In an embodiment of the application, the periodic filling of tokens according to the initialized device under test to perform the filling verification of each token bucket includes steps S11-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 token number between each adjacent period during the filling process and the current token number after the filling is completed.

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

[0082] In an embodiment of the application, comparing the current token number between each adjacent period during the filling process and the current token number after the filling is completed of each token bucket with the first preset configuration information to realize the filling verification of each token bucket includes steps S121-S124.

[0083] Step S121, obtaining the token number increment of each token bucket in each period according to the current token number of each token bucket between adjacent periods in the filling process.

[0084] Step S122, comparing the token number increment of each token bucket in each period and the current token number after the filling is completed with the first preset configuration information to obtain a comparison result.

[0085] Step S123, if the token number increment of each token bucket in each period is the same as the token bucket filling rate in the first preset configuration information, and the current token number of each token bucket after the filling is completed is the same as the token bucket depth in the first preset configuration information, the comparison result is that the filling verification of each token bucket is passed.

[0086] Step S124, otherwise, the comparison result is that the filling verification of each token bucket is failed.

[0087] Specifically, if the comparison result is correct, it indicates that the filling verification of each token bucket of the to-be-tested device is successful, if the comparison result is incorrect, the filling verification of each token bucket of the to-be-tested device is failed, indicating that the to-be-tested device has an error or the token bucket calculation is incorrect. The filling verification process must not send any message, so that the token bucket can always maintain the state of only adding and not reducing, so that only reading the token bucket by period is needed to complete the correctness test of the token bucket filling.

[0088] In an embodiment of the present application, the steps S21 to S23 are included in the process of respectively inputting the same message information to the initialized to-be-tested device and the initialized reference model of the first mode to perform the token bucket deduction verification.

[0089] Step S21, obtaining the first to-be-tested device output information according to the message information input by the initialized to-be-tested device; the message information includes at least one message; the first to-be-tested device output information includes the output packet corresponding to each message. Wherein, the message content includes but is not limited to the message length and the token bucket number.

[0090] Step S22, obtaining the reference model output information of the first mode according to the same message information input by the initialized reference model of the first mode; the reference model output information of the first mode includes the output packet corresponding to each message.

[0091] Specifically, the application performs packet analysis according to input packet information to obtain analyzed packet information; obtains corresponding hit token buckets according to the analyzed packet information and a reference model of the first mode after initialization configuration; performs bucket deduction processing according to the hit token buckets to obtain reference model output information of the first mode; the reference model output information of the first mode includes output packets corresponding to each packet; the output packet includes packet marker information of a current packet and a remaining token number of a hit token bucket. For example, a corresponding hit token bucket is obtained according to the analyzed token bucket number in the reference model of the first mode after initialization configuration.

[0092] Step S23, packet comparison is respectively performed on the output packets corresponding to each packet in the first device under test output information and the output packets corresponding to each packet in the reference model output information of the first mode to realize bucket deduction verification of each token bucket.

[0093] In an embodiment of the application, the output packets corresponding to each packet include packet marker information of a current packet and a remaining token number of a hit token bucket; packet comparison is respectively performed on the output packets corresponding to each packet in the first device under test output information and the output packets corresponding to each packet in the reference model output information of the first mode to realize bucket deduction verification of each token bucket, including steps S231 to S233.

[0094] Step S231, packet comparison is performed on packet marker information of a current packet and a remaining token number of a hit token bucket in the output packets corresponding to each packet in the first device under test output information and the output packets corresponding to each packet in the reference model output information of the first mode to obtain a comparison result.

[0095] Step S232, if the packet marker information of the current packet in the output packets corresponding to each packet in the first device under test output information and the packet marker information of the current packet in the output packets corresponding to each packet in the reference model output information of the first mode are the same, and the remaining token number of the hit token bucket in the output packets corresponding to each packet in the first device under test output information and the remaining token number of the hit token bucket in the output packets corresponding to each packet in the reference model output information of the first mode are the same, the comparison result indicates that the bucket deduction verification of each token bucket is passed.

[0096] Step S233, otherwise, the comparison result indicates that the bucket deduction verification of each token bucket is not passed.

[0097] Specifically, the application sends a plurality of packets after the initialization configuration of the to-be-tested device and the reference model of the first mode is completed, respectively analyzes each packet, randomly hits the corresponding token bucket according to each analyzed packet information, and the reference model of the first mode receives the analyzed packet information and compares the number of tokens consumed with the number of remaining tokens in the token bucket. If the number of remaining tokens is more, the packet is marked as forwarded, otherwise the packet is marked as discarded. In this way, the packet marking information of each packet and the number of remaining tokens in each token bucket can be obtained. Similarly, the to-be-tested device receives each packet and obtains the packet marking information of each packet and the number of remaining tokens in each token bucket. The packet marking information of each packet and the number of remaining tokens in each token bucket output by the to-be-tested device are compared with the packet marking information of each packet and the number of remaining tokens in each token bucket output by the reference model of the first mode. If they are consistent, it means that the comparison is correct, and the token bucket verification of each token bucket in the to-be-tested device is successful. Otherwise, it means that the comparison is incorrect, and the token bucket verification of each token bucket in the to-be-tested device fails, indicating that the to-be-tested device has an error or the reference model is written incorrectly.

[0098] In an embodiment of the application, the rate verification of each token bucket is performed by respectively inputting the same mixed packet information into the initialized to-be-tested device and the initialized reference model of the second mode, which includes the following steps S31 to S33.

[0099] Step S31, obtaining second to-be-tested device output information according to the mixed packet information input into the initialized to-be-tested device; the mixed packet information includes a plurality of packets of different priorities; and the second to-be-tested device output information includes output packets corresponding to each packet.

[0100] Step S32, obtaining second mode reference model output information according to the same mixed packet information input into the initialized reference model of the second mode; the second mode reference model output information includes output packets corresponding to each packet.

[0101] Specifically, the application respectively analyzes the input mixed packet information to obtain corresponding analyzed packet information, obtains the corresponding hit token bucket according to the analyzed packet information and the initialized reference model of the second mode, and obtains the corresponding second mode reference model output information by token bucket processing. The second mode reference model output information includes output packets corresponding to each packet. The output packet includes packet marking information of the current packet and the number of remaining tokens in the hit token bucket. For example, the hit token bucket is obtained according to the analyzed token bucket number in the initialized reference model of the first mode.

[0102] Step S33, comparing the flow rates of the output packets corresponding to each packet in the second to-be-tested device output information and the output packets corresponding to each packet in the second mode reference model output information to achieve rate verification of each token bucket.

[0103] In an implementation, the mixed packet information includes several packets with different rates, and the mixed packet information includes, but is not limited to, green packets, yellow packets and / or red packets. The packet with a greater rate has a higher priority, and the priority order of the three packets is green packet > yellow packet > red packet.

[0104] In an embodiment of the present application, each packet includes packet length and token bucket number; the output packet corresponding to each packet includes packet marking information of the current packet and the remaining token number of the hit token bucket; and the flow rate comparison of the output packets corresponding to each packet in the second to-be-tested device output information and the output packets corresponding to each packet in the second mode reference model output information to achieve rate verification of each token bucket includes the following steps S331 to S336.

[0105] Step S331, performing shunt statistics on each output stream in the second to-be-tested device output information to obtain the output stream rate of each output stream.

[0106] Step S332, selecting the packet marking information of the packets in the second to-be-tested device output information as the forwarded packets according to the output packets corresponding to each packet, calculating the output stream rate of 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 packets with the same priority in each hit token bucket; the output stream rate is the sum of the packet lengths of the packets in the current output stream divided by the total time of the to-be-tested device processing the mixed packet information; and the packet information includes forwarding and discarding.

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

[0108] Step S334, comparing the output stream rate of each output stream in each hit token bucket calculated according to the second to-be-tested device output information with the output stream rate of each output stream in each hit token bucket calculated according to the second mode reference model output information to obtain a comparison result.

[0109] Step S335, if the output flow rates of each output flow corresponding to each hit token bucket calculated according to the second to-be-tested device output information are the same as the output flow rates of each output flow corresponding to each hit token bucket calculated according to the reference model output information of the second mode, the comparison result is that the rate verification of each token bucket is passed.

[0110] Step S336, otherwise, the comparison result is that the rate verification of each token bucket is failed.

[0111] Specifically, after the initialization and configuration of the to-be-tested device and the reference model of the second mode are completed, the packet sending component with controllable rate is used to send packets with different random rates to each token bucket at the same time for a long time. Each packet is parsed, and each parsed packet information is randomly hit to the corresponding token bucket. During the packet sending process, the rate monitoring component is used to distinguish each output flow corresponding to each token bucket, and different flows should not be confused. After the packet sending is completed, the output rates of each output flow are counted. Here, only the packets with forwarding packet marking information in the output packets corresponding to each input packet are counted. The output packets here are the same as the output packets in the token bucket, and both include the packet marking information of the current packet and the remaining token number of the hit token bucket. After the output flow rates of each token bucket corresponding to each output flow in the to-be-tested device and the reference model of the second mode are counted, the output flow rates of each output flow are compared. If the output rates of each output flow are the same, it means that the rate verification of each token bucket in the to-be-tested device is successful, that is, the rate verification of each token bucket in the to-be-tested device is successful, otherwise, it means that the rate verification of each token bucket in the to-be-tested device is failed, and the to-be-tested device has an error or the reference model is written incorrectly.

[0112] In an embodiment, the token bucket algorithm model of a single-speed double-bucket three-color token bucket specified by the RFC2697 protocol is used to evaluate the packet flow. According to the evaluation result, the packet is marked with the following three colors-green, yellow and red. This algorithm has two token buckets C bucket and E bucket, and the bucket depths are CBS (Committed Burst Size, committed burst size) and EBS (Excess Burst Size, excess burst size), respectively. The filling rates of the two token buckets are CIR (Committed Information Rate, committed information rate).

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

[0114] Figure 4 A single-speed double-bucket filling token schematic diagram is shown in the embodiment of the application. Figure 5 A single-speed double-bucket deduction token schematic diagram is shown in the embodiment of the application. As shown in Figures 4-5 When filling tokens, the application will first add tokens to the C bucket at the rate of CIR, and then continue to add tokens to the E bucket until the E bucket is also filled. The specific process is shown in Figure 4 When processing messages, green, yellow and red messages will be received, and tokens will be deducted and cannot be in deficit. Green messages will first deduct C bucket tokens and be marked as green. When the C bucket tokens are insufficient, the C bucket will be skipped to deduct E bucket tokens and be marked as yellow. If the E bucket tokens are insufficient, no tokens will be deducted and output as red. Yellow messages will directly skip the C bucket to deduct E bucket tokens and be marked as yellow. If the E bucket tokens are insufficient, no tokens will be deducted and output as red. Red messages will not deduct any tokens and will be directly output as red. The specific process is shown in Figure 5 In addition, there is a color blindness mode, which is equivalent to considering all input messages as green messages.

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

[0116] Figure 6 A bucket filling test flowchart is shown in the embodiment of the application. Figure 7 A bucket deduction test flowchart is shown in the embodiment of the application. Figure 8 A rate verification flowchart is shown in the embodiment of the application. Figure 9 An RFC2697 flow monitoring schematic diagram is shown in the embodiment of the application.

[0117] Figure 6 A bucket filling test flowchart is shown in the embodiment of the application. As shown in Figure 6As shown, the present application first randomly configures the token bucket depth and the token bucket filling rate of the C bucket and the E bucket in all token buckets in the device under test according to the first preset configuration information as any reasonable value, and configures the initial token number of the token bucket as 0, and then enables all the token buckets. After the initialization configuration is completed and the token buckets are enabled, the filling completion signal inside the device under test can be obtained. After the first filling completion pulse is obtained, the token numbers in the C bucket and the E bucket in all token buckets are read out in sequence through the configuration communication channel (the communication bus for realizing the initialization configuration) for recording and comparison with the theoretical value of the first preset configuration information. This process must be completed before the next filling cycle is obtained. When the next filling completion pulse arrives, the reading and comparison are still completed according to the above steps, and the operation is repeated in this way for several times until all the token buckets are filled, and the verification is ended after the comparison of the operation of several more cycles is completed.

[0118] The token number comparison rule in the token bucket is as follows.

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

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

[0121] Step S43, when the tokens in the C bucket and the E bucket are filled, since there is no consumption of tokens in this stage of verification, no filling will be performed, CIR will continue to overflow, and all the token buckets should observe that the token numbers in the C bucket and the E bucket remain unchanged and consistent with their depths.

[0122] Figure 7 The token bucket test flowchart described in the embodiment of the present application is shown. As Figure 7As shown, the present application first randomly configures the bucket depth and initial token number of all C buckets and E buckets as any reasonable value, randomly configures the color blindness and color sensitivity mode, and configures the fill rate CIR as 0. At the same time, in the reference model of the verification environment, the token buckets of the same group are also instantiated, and each group is given the same initialization configuration as the DUT. After completing the initialization configuration, a plurality of mixed color packets are sent, and different token buckets are randomly hit. The internal token bucket of the DUT processes the packet according to the logic mentioned above and marks the new color output, and the reference model needs to simulate the behavior of the DUT, and continuously adjust the reference model and the DUT until the following two points are met, which can be considered as verification passed. One is that the number and color of the DUT output packets are consistent with the output of the reference model, and the other is that the remaining token number of all token buckets C and E is read at the end of the simulation, and the remaining amount of token buckets of each group of the DUT and the reference model is also completely consistent.

[0123] The token bucket processing required by the reference model is as follows steps S51 to S54.

[0124] Step S51, receiving a green packet, first judging whether the remaining token of the C bucket can deduct the token required by the packet, if so, deducting the token from the C bucket and marking the yellow output. If the token of the C bucket is not enough to deduct, it is necessary to jump over the C bucket to judge whether the remaining token of the E bucket can deduct, if so, deducting the token from the E bucket and marking the yellow output, otherwise marking the red output.

[0125] Step S52, receiving a yellow packet, directly jumping over the C bucket to judge whether the remaining token of the E bucket can deduct the token required by the packet, if so, deducting the token from the E bucket and marking the yellow output, otherwise marking the red output.

[0126] Step S53, receiving a red packet, directly marking the red output.

[0127] Step S54, if the token bucket is configured as a color blindness mode, the input packet can be regarded as green, and all received packets are processed according to step S51.

[0128] Figure 8 The rate verification flowchart described in the embodiment of the present application is shown. Figure 9 The RFC2697 traffic policing principle diagram described in the embodiment of the present application is shown. Figures 8-9As shown, the application firstly randomly configures the bucket depth and filling rate CIR of all token buckets C bucket and E bucket as any reasonable value, and configures the initial token number as a small value, and then enables each group of token buckets. After completing the initialization configuration, the packet sending component with controllable rate is used to simultaneously send three-color packets to each group of token buckets, and the rate of each color can be random, lasting for a long period of time. After the packet sending is completed, the input and output rates of various color packets of each group of token buckets are respectively counted, and comparison and monitoring are performed according to certain rules. If all are consistent with the expectation, the performance test verification is completed.

[0129] The rate monitoring rules are as follows: steps S61 to S62.

[0130] Step S61, in the color blindness mode, this algorithm can only realize the flow monitoring of yellow packets and green packets. If the total rate of input packets is less than CIR, it is necessary to monitor that the rate of output packets is consistent with the input rate and all green packets. If the total rate of input packets exceeds CIR, the C bucket will be unable to be filled for a long time, and the E bucket will always be unable to be filled. At this time, it should be monitored that the output green packets and the rate are CIR, and the output red packets and the rate are the total rate of input packets minus CIR, and the yellow flow is extremely small and can be ignored.

[0131] Step S62, in the color sensitivity mode, this algorithm can only realize the flow monitoring of three-color packets. In this mode, the input red packets are all converted into red, and if the sum of the green packet rate and the yellow packet rate does not exceed CIR, at this time, the output three-color packet rate is consistent with the input. If the input green packet rate does not exceed CIR but the green plus yellow exceeds CIR, the output green packet rate is consistent with the input, the yellow packet rate is CIR minus the green rate, and the rest is red. If the input green packet rate exceeds CIR, the output green packet and the rate are CIR, and the output red packet and the rate are the total rate of input packets minus CIR, and the yellow flow is extremely small and can be ignored.

[0132] The token bucket verification method proposed in the application can realize universal verification for token bucket algorithms of various different protocols.

[0133] In an embodiment, if all the token bucket configuration options are configured randomly at one time according to a conventional verification method, and random flow is performed to each token bucket, then a simple comparison is made between the reference model and the output of the DUT to determine whether they are consistent. A lot of effort is then required to write the reference model, and for each algorithm, the read-write timing of the DUT needs to be strictly synchronized. The filling period, the order in which each token bucket is filled, the timing of the deduction, and the deduction just after the token bucket is filled, all need to be processed in exactly the same way as the DUT, so that the reference model that meets the requirements can be written. Because the timing of the deduction or filling of the token bucket is earlier or later than the DUT, the real-time token number of the reference model maintained by the token bucket when performing packet forwarding arbitration is inconsistent with the DUT, which can cause the DUT to falsely report a packet loss while the reference model does not, or the DUT does not lose a packet while the reference model does. In order to avoid such false positives, a lot of time is often spent debugging the timing of the reference model to make it complete. Even if the debugging is complete, once the timing of a certain part of the DUT is modified (for example, the timing is modified due to the replacement of the RAM), the timing of the reference model also needs to be modified synchronously, which takes a lot of time, and part of the time may be wasted due to changes in the scheme. The reference model written in this way, even if it is perfect, is not conducive to reuse. If dynamic performance testing is performed directly, a lot of simulation time is required to reduce the calculation error of EDA simulation at the beginning, and some small bugs that are easy to encounter at the beginning of verification can be located by simple basic use cases. In order to solve such problems, a lot of time is spent on loading waveforms at the beginning, which is very inefficient, and too large a waveform is not conducive to locating the initial node where the problem occurs. These are the pain points that cannot be avoided in EDA simulation testing of all token bucket algorithms or even large flows. The three-step token bucket verification strategy proposed in the present application has the core idea of first decomposing the complex dynamic processing logic of the token bucket into independent filling and deduction logic, and then separating the filling and deduction to verify and exclude most bugs. After completion, dynamic performance testing is performed, which can improve efficiency and ensure the completeness of the verification. The three stages of testing can verify different bugs respectively, and are also complementary and dependent on each other. The specific problems that can be solved in each step of the testing process are described in detail below.

[0134] The first stage of the bucket filling test is the only one that needs to synchronize the DUT signal among the three steps, but it does not need to write a reference model, and the interface can be directly connected to the key signal inside the DUT, and then the test is expected to complete the verification in the verification case. Although the filling completion signal of the DUT needs to be synchronized, it only needs to check the token bucket filling value between the two times of receiving the signal, and the time node requirement is not strict. As long as the use case is complete, even if the timing of the DUT is modified, only the synchronization signal of the interface connection needs to be modified. Such changes are small and very conducive to reuse, and even if the project is switched to a different project, the reusability of such cases is quite considerable. In the field of EDA (Electronic Design Automation), interface refers to a kind of interface in the data acquisition standard of semiconductor equipment.

[0135] The second stage of the bucket deduction test is slightly more complex and requires maintaining a reference model. However, since the interference of the bucket filling is excluded and the logic of adding tokens to the token bucket is removed, timing issues are almost not considered. If a fully functional reference model is directly written, it is inevitable that the bucket will be earlier or later than the DUT, causing the token bucket to make mistakes in message arbitration. The simplified model, although it lacks some functions, greatly improves code efficiency and accuracy of comparison. Moreover, it can be modified on the basis of the original token bucket algorithm logic to add more complex logic, such as the aforementioned pre-stage packet loss not entering the token bucket arbitration, the token bucket authorized packet being discarded by the post-stage packet loss logic, and special packets being able to skip the token bucket algorithm. These scenarios can be implemented by the reference model receiving the packet, whether to deduct tokens, whether to add a discard flag, and the DUT to achieve complete synchronization between packets. In summary, although this reference model gives up part of the function comparison, it obtains more efficient and fast code, and has strong expandability, providing a fast and feasible way for the reference model to integrate token bucket algorithm and other complex functions for verification.

[0136] The third stage of dynamic rate test is closest to the scene in actual application and is indispensable. After the first and second stages of test are completed, if all the discovered bugs are excluded one by one, it can be basically confirmed that the description of the code and the design scheme is consistent. At this time, the third step test can only further ensure that the performance of the token bucket meets the standard, and maybe no new bug will be found, but this step is still indispensable. Because the previous two steps are based on the microscopic comparison of packets or the comparison of the number of tokens in the token bucket, these are not enough to show that this scheme meets the needs. Since the token bucket algorithm is mostly used for rate control or flow regulation, it must also be verified in the macro flow test to increase the authenticity of the verification process and ensure that the scheme does not fail in actual operation. If the test in this stage fails and the performance does not meet the standard, after excluding the calculation error, if the problem still exists, it can also promote the re-examination of whether the initial design scheme has unreasonable details in the implementation details.

[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 the embodiments, and any scheme realized by adding, replacing or replacing steps of the prior art 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 also provide a token bucket verification system, which can implement the token bucket verification method described in the present application, but 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 the embodiments. Any structure deformation and replacement of the prior art according to the principle of the present application is included in the protection scope of the present application.

[0139] As shown in Figure 10 The embodiments of the present application provide a token bucket verification system, and the system 200 includes:

[0140] The bucket filling verification module 211 is configured to initialize and configure the to-be-tested device according to first preset configuration information, and periodically fill tokens in the to-be-tested device after initialization 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; and the to-be-tested device includes at least one token bucket.

[0141] The bucket verification module 212 is configured to initialize the to-be-tested device and the reference model of the first mode based on second preset configuration information respectively, and input the same packet information to the initialized to-be-tested device and the initialized reference model of the first mode to perform the bucket verification of each token bucket. The second preset configuration information includes a token bucket depth and an initial token number of the token bucket. The reference model of the first mode is a model having the same function as the to-be-tested device. 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.

[0142] The rate verification module 213 is configured to initialize the to-be-tested device and the reference model of the second mode based on third preset configuration information respectively, and input the same mixed packet information to the initialized to-be-tested device and the initialized reference model of the second mode to perform the rate verification of each token bucket. The third preset configuration information includes a token bucket depth, a token bucket filling rate and an initial token number of 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.

[0143] It should be noted that the functions or operations of the bucket filling verification module 211, the bucket verification module 212 and the rate verification module 213 described in the embodiments of the present disclosure correspond to the steps in the token bucket verification method described above one by one, and therefore will not be described here.

[0144] In several embodiments provided in the present application, it should be understood that the disclosed system, device or method can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules / units is only a logical function division. In actual implementation, another division mode can be used, for example, a plurality of modules or units can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed ones can be indirect coupling or communication connection through some interfaces, devices or modules or units, which can be electrical, mechanical or other forms.

[0145] The modules / units described as separate components can or can not be physically separated, and the components shown as modules / units can or can not be physical modules, i.e., they can be located in one place or distributed on multiple network units. Part or all of the modules / units can be selected according to actual needs to achieve the purpose of the embodiments of the present application. For example, the functional modules / units in each embodiment of the present application can be integrated into one processing module, or each module / unit can be physically separated, or two or more modules / units can be integrated into one module / unit.

[0146] Those skilled in the art should further understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been described in the above description in a general manner. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0147] Figure 11 is a schematic block diagram of an electronic device provided by an embodiment of the present application. As shown in Figure 11 , the electronic device 300 includes at least one processor 311, a memory 312, at least one network interface 313 and a user interface 314. Each component in the apparatus is coupled together through a bus system. It can be understood that the bus system is used to realize the connection communication between the components. The bus system includes a data bus in addition to a power bus, a control bus and a status signal bus. However, for the purpose of clarity, all kinds of buses are marked as a bus system in Figure 11 .

[0148] The user interface 314 can include a display, a keyboard, a mouse, a trackball, a click gun, a key, a button, a touchpad or a touch screen, etc.

[0149] It can be understood that the memory 312 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. The non-volatile memory can be a read-only memory (ROM, Read Only Memory), a programmable read-only memory (PROM, Programmable Read-Only Memory), which is used as an external cache. By way of example but not limitation, many forms of RAM can be used, such as static random access memory (SRAM, Static Random Access Memory), synchronous static random access memory (SSRAM, Synchronous Static Random Access Memory). The memory described in the embodiments of the present application is intended to include but not limited to these and any other suitable categories of memory.

[0150] The memory 312 in the embodiments of the present application is configured to store various types of data to support the operation of the electronic device 300. Examples of the data include any executable programs for operating on the electronic device 300, such as an operating system 3121 and application programs 3122. The operating system 3121 includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, for implementing various basic services and processing hardware-based tasks. The application programs 3122 can include various application programs, such as a media player, a browser, and the like, for implementing various application services. The token bucket verification method provided in the embodiments of the present application can be included in the application programs 3122.

[0151] The method disclosed in the embodiments of the present application can be applied to the processor 311 or implemented by the processor 311. The processor 311 can be an integrated circuit chip having a processing capability of signals. In the implementation process, each step of the above method can be completed by an integrated logic circuit or an instruction in the form of software in the processor 311. The processor 311 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. The processor 311 can implement or execute the disclosed methods, steps, and logic block diagrams in the embodiments of the present application. The general-purpose processor 311 can be a microprocessor or any conventional processor, and the like. In combination with the steps of the token bucket verification method provided in the embodiments of the present application, the hardware decoding processor can be directly embodied to complete the execution, or a combination of hardware and software modules in the decoding processor can be used to complete the execution. The software module can be located in a storage medium, which is located in the memory. The processor reads the information in the memory and combines the hardware to complete the steps of the foregoing method.

[0152] In the exemplary embodiments, the electronic device 300 can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), or the like, for executing the foregoing method.

[0153] The embodiments of the present application further provide a computer readable storage medium. Those skilled in the art can understand that all or part of the steps of the methods described in the above embodiments can be instructed by a program to complete the processor, and the program can be stored in a computer readable storage medium. The storage medium is a non-transitory medium, for example, a random access memory, a read-only memory, a flash memory, a hard disk, a solid state disk, a magnetic tape, a floppy disk, an optical disc and any combination thereof. The storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, a data center and the like, which includes one or more available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a digital video disc (DVD)) or a semiconductor medium (for example, a solid state disk (SSD)) and the like.

[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 computer readable storage medium, for example, the computer instructions can be transmitted from one website, computer or data center to another website, computer or data center through wired (for example, coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (for example, infrared, wireless, microwave and the like) mode.

[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, and when the foregoing method is needed, the computer program product can be downloaded and executed on the computer.

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

[0157] The three-step token bucket verification method proposed in the application first disassembles the complex dynamic processing logic of the token bucket into independent filling and deducting logic, first separates the filling and deducting logic, and then performs verification to exclude most bugs. After completion, dynamic performance testing is performed, which can improve efficiency and ensure the completeness of verification. The three stages of testing can verify different bugs respectively, and are complementary and dependent on each other. For token bucket algorithms of various protocols, universal verification can be achieved.

[0158] In the filling verification stage, the application does not need to send any message, so that the token bucket can always remain in the state of only adding and not reducing, so that only reading the token bucket at a constant period can complete the correctness test of the token bucket filling, which has little change and high reuse for token bucket verification of different protocols.

[0159] In the deducting verification stage, the application always sends packets and does not allow the device under test to fill the token bucket, so that the token bucket always remains in the state of only reducing and not adding, and then combines the packet output result obtained by the reference model of the first mode to complete the correctness test of the token bucket deducting. Since no conflict processing is required, this process greatly simplifies the complexity of the reference model of the first mode and reduces the human cost required for programming.

[0160] In the rate verification stage, the application is close to the scene in real application, and needs to combine packet sending at a certain rate and periodic filling of the token bucket. The difficulty lies in that the rate of input packets and the rate of output flow cannot have statistical errors. By monitoring the rate of each output flow to meet the expectation, the performance test of the token bucket is completed.

[0161] The descriptions of the processes or structures corresponding to the above respective figures each have different focuses. The parts not described in detail in a certain process or structure can be referred to the related descriptions of other processes or structures.

[0162] The above embodiments only exemplarily illustrate the principles and effects of the application, and are not used to limit the application. Any person skilled in the art can modify or change the above embodiments without departing from the spirit and scope of the application. Therefore, all equivalent modifications or changes made by those skilled in the art without departing from the spirit and technical thought of the application should be covered by the claims of the application.

Claims

1. A token bucket verification method, characterized in that, The method includes: The device under test is initialized and configured according to the first preset configuration information. Tokens are periodically filled into the device under test after initialization to perform token bucket filling verification. The first preset configuration information includes token bucket depth and token bucket filling rate. The device under test includes at least one token bucket. Based on the second preset configuration information, the device under test (DUT) and the reference model of the first mode are initialized and configured respectively. The same message information is input to the initialized DUT and the initialized reference model of the first mode to perform token bucket deduction verification. 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 performs the same function as the DUT. The first mode is a mode in the reference model that enables packet comparison and disables flow classification collection and comparison. Based on the third preset configuration information, the device under test and the reference model of the second mode are initialized and configured respectively. The same mixed message information is input to the initialized device under test and the initialized reference model of the second mode to perform rate verification of each token bucket. The third preset configuration information includes token bucket depth, token bucket filling rate and initial number of tokens in the token bucket. The second mode is a mode in the reference model where packet comparison is turned off and flow classification collection and comparison are turned on.

2. The token bucket verification method according to claim 1, characterized in that, The token filling verification for each token bucket is performed periodically based on the initialized device under test, including: The device under test is periodically filled with tokens according to the initial configuration to obtain filling token information; the filling token information includes the current number of tokens between each adjacent period during the filling process and the current number of tokens after filling is completed; The token bucket filling verification is achieved by comparing the current token count between adjacent cycles during the filling process and the current token count after filling is completed with the first preset configuration information.

3. The token bucket verification method according to claim 2, characterized in that, The token bucket filling verification is achieved by comparing the current token count between adjacent cycles during the filling process and the current token count after filling with the first preset configuration information, including: The token count increment for each token bucket between each cycle is obtained based on the current token count between each adjacent cycle during the filling process of each token bucket. The comparison results are obtained by comparing the token count increment of each token bucket in each cycle and the current token count after filling with the first preset configuration information; If the token count increment between each token bucket in each cycle is the same as the token bucket filling rate in the first preset configuration information, and the current token count after each token bucket is filled 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 fails.

4. The token bucket verification method according to claim 1, characterized in that, Inputting the same message information into both the initialized device under test and the initialized first-mode reference model to perform token bucket deduction verification includes: The first device under test (DUT) output information is obtained based on the initialized input message information of the DUT; the message information includes at least one message; the first DUT output information includes the output packets corresponding to each message. The reference model output information of the first mode is obtained by inputting the same message information as the reference model of the first mode after initialization; the reference model output information of the first mode includes the output packets corresponding to each message; The output packets corresponding to each message in the output information of the first device under test and the output packets corresponding to each message in the output information of the reference model of the first mode are compared to realize the buckle verification of each token bucket.

5. The token bucket verification method according to claim 4, characterized in that, The output packet corresponding to each message includes the message tagging information of the current message and the number of remaining tokens in the token bucket that has been hit; the token bucket deduction verification is achieved by comparing the output packets corresponding to each message in the output information of the first device under test and the output packets corresponding to each message in the reference model output information of the first mode, including: The packet comparison is performed based on the message tag information of the current message and the number of remaining tokens in the token bucket of each message in the output packet corresponding to each message in the output information of the reference model of the first mode, and the comparison results are obtained. If the message tag information of the current message in the output packet corresponding to each message in the output information of the first device under test is the same as the message tag information of the current message in the output packet corresponding to each message in the output information of the reference model of the first mode, and the number of remaining tokens hitting the token bucket in the output packet corresponding to each message in the output information of the first device under test is the same as the number of remaining tokens hitting the token bucket in the output packet corresponding to each message in the output information of the reference model of the first mode, then the comparison result indicates that the token bucket deduction verification is passed. Otherwise, the comparison result is that the token bucket verification fails.

6. The token bucket verification method according to claim 1, characterized in that, The same mixed message information is input to both the initialized device under test and the initialized second-mode reference model to perform rate verification for each token bucket, including: The second device under test (DUT) output information is obtained based on the mixed message information input by the DUT after initialization; the mixed message information includes several messages of different priorities; the second DUT output information includes the output packets corresponding to each message. The reference model output information of the second mode is obtained by inputting the same mixed message information based on the reference model of the initialized second mode; the reference model output information of the second mode includes the output packets corresponding to each message; The flow rate is compared with 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 reference model of the second mode to realize the rate verification of each token bucket.

7. The token bucket verification method according to claim 6, characterized in that, Each message includes a message length and a token bucket number; the output packet corresponding to each message includes the message tagging information of the current message and the number of remaining tokens that hit the token bucket; the flow rate is compared with 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 reference model output information of the second mode to realize the rate verification of each token bucket, including: Based on the output packets corresponding to each message in the output information of the second device under test, messages marked as forwarding are selected. The output flow rate corresponding to each output flow in each hit token bucket is calculated based on the message length and token bucket number of the selected messages. 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 the device under test processes the mixed message information. The message information includes forwarding and dropping. Based on the output packet corresponding to each message in the reference model output information of the second mode, select the message marking information as the message to be forwarded, and calculate the output flow rate corresponding to each output flow in each hit token bucket based on the message length and token bucket number of the selected message. The output flow rate corresponding to each output stream in each hit token bucket, calculated based on the output information of the second device under test, is compared with the output flow rate corresponding to each output stream in each hit token bucket, calculated based on the output information of the reference model of the second mode, and the comparison results are obtained. If the output flow rate corresponding to each output flow in each hit token bucket calculated based on 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 calculated based on the reference model output information of the second mode, 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 fails.

8. A token bucket verification system, characterized in that, The system includes: The token bucket filling verification module is configured to initialize the device under test according to the first preset configuration information, and periodically fill tokens according to the initialized device under test to perform token bucket filling verification for each token bucket; the first preset configuration information includes token bucket depth and token bucket filling rate; the device under test includes at least one token bucket; The token bucket verification module is configured to initialize the device under test (DUT) and the reference model of the first mode based on a second preset configuration information. It then inputs the same message information into both the initialized DUT and the initialized reference model of the first mode to perform token bucket verification. 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 performs the same function as the DUT. The first mode is a mode in the reference model where packet comparison is enabled, and flow classification and acquisition are disabled. The rate verification module is configured to initialize the device under test and the reference model of the second mode based on a third preset configuration information, and to input the same mixed packet information into the initialized device under test and the initialized reference model of the second mode to perform rate verification of each token bucket; the third preset configuration information includes token bucket depth, token bucket filling rate and initial token number in the token bucket; the second mode is a mode in the reference model where packet comparison is disabled and flow classification acquisition and comparison are enabled.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory; wherein... The memory is used to store computer programs; The processor is used to execute the computer program stored in the memory to cause the electronic device to perform the token bucket verification method as 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 executed by an electronic device, the program implements the token bucket verification method as described in any one of claims 1 to 7.

Images