Method and system for facilitating data transmission in a switch

Abstract

Embodiments of the present disclosure relate to methods and systems for instrument compliance in a switch. A system for facilitating data transmission in a switch is provided. During operation, the system may obtain one or more configuration parameter sets for multiple business supervision filters of the switch. The corresponding business supervision filter may correspond to a token bucket. The number of tokens in the token bucket may indicate whether to forward a packet associated with the business supervision filter. The system may determine a token allocation frequency for multiple business supervision filters based on one or more configuration parameter sets. Then, the system may select a sampling interval from the token allocation frequency based on a selection strategy and determine an execution rate for the multiple business supervision filters based on the sampling interval.

Description

Technical Field

[0001] The present disclosure relates to communication networks. More particularly, the present disclosure relates to methods and systems for determining compliance of meters associated with classifier policies in switches. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1A An exemplary network that facilitates efficient meter compliance in switches according to embodiments of the present application is illustrated.

[0003] Figure 1B An exemplary switch structure that facilitates efficient meter compliance in a switch according to an embodiment of the present application is illustrated.

[0004] Figure 2A An exemplary selection of a sampling interval for determining compliance of a traffic meter associated with a classifier policy in a switch according to an embodiment of the present application is illustrated.

[0005] Figure 2B An exemplary selection of time intervals for determining compliance of traffic meters associated with different classifier policies in a switch according to an embodiment of the present application is illustrated.

[0006] Figure 2C The figure illustrates an exemplary configuration of a service meter in different classifier policies in a switch according to an embodiment of the present application.

[0007] Figure 3A An exemplary selection of sampling intervals for determining compliance with hierarchical serial traffic instrumentation in a switch according to an embodiment of the present application is illustrated.

[0008] Figure 3B An exemplary selection of sampling intervals for determining compliance with hierarchical parallel traffic metering in a switch according to an embodiment of the present application is illustrated.

[0009] Figure 3C An exemplary selection of sampling intervals for determining compliance of heterogeneous traffic meters associated with classifier policies in a switch according to an embodiment of the present application is illustrated.

[0010] Figure 4 A flow chart illustrating a process of a traffic management system of a switch determining a sampling interval of a classifier policy according to an embodiment of the present application is presented.

[0011] Figure 5A A flow chart illustrating a process of facilitating a traffic management system of a switch for compliance information of traffic meters associated with classifier policies according to an embodiment of the present application is presented.

[0012] Figure 5BA flow chart illustrating a process of a traffic management system for determining a switch sampling interface for determining compliance information according to an embodiment of the present application is presented.

[0013] Figure 6 An exemplary switch supporting efficient meter compliance according to an embodiment of the present application is illustrated.

[0014] In the various drawings, the same reference numerals refer to the same drawing elements. DETAILED DESCRIPTION

[0015] The following description is intended to enable those skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Therefore, the present invention is not limited to the embodiments shown, but is to be consistent with the widest scope consistent with the claims.

[0016] Overview

[0017] The Internet is the delivery medium for a variety of applications running on physical and virtual devices. Such applications have brought about an ever-increasing demand for services. As a result, equipment vendors are competing to build switches that can effectively forward different categories of services. To this end, switches can facilitate service regulation to protect the network from service overflow or unmanaged bursts of service. Network administrators can manage a set of rate limit parameters to ensure that services are transmitted within these parameters. For each category of service, the network administrator can configure a classifier policy for the meter (or regulator) that indicates the corresponding limit parameters. If the packet meets the meter of the classifier policy, the switch can forward the message. In this way, the parameters can operate as service meters and facilitate flow control on the switch.

[0018] However, a network administrator may need to monitor bandwidth usage to determine the extent to which classifier policies are managing traffic from a switch. To help network administrators monitor bandwidth usage, switches can report data transmission rates during a sampling period for corresponding classifier policies. Due to changes in rate limiting parameters and sampling periods, traditional rate reporting may be inaccurate, slow to reflect changes in traffic, or may require significant computational overhead (e.g., due to intensive use of switch hardware). Although classifier policies can bring many desirable features to traffic management, some issues regarding reporting compliance of instruments in switches remain unresolved.

[0019] One embodiment of the present technology provides a system for facilitating data transmission in a switch. During operation, the system may obtain one or more configuration parameter sets for multiple service supervision filters of the switch. The corresponding service supervision filter may correspond to a token bucket. Multiple tokens in the token bucket may indicate whether to forward a packet associated with the service supervision filter. The system may determine a token allocation frequency for the multiple service supervision filters based on the one or more configuration parameter sets. Then, the system may select a sampling interval from the token allocation frequency based on a selection policy, and determine an execution rate for the multiple service supervision filters based on the sampling interval.

[0020] In a variation of this embodiment, a corresponding configuration parameter set in the one or more configuration parameter sets includes an information rate and a burst size of a token bucket.

[0021] In a variation of this embodiment, the execution rate may include compliance rates of multiple service supervision filters.The system may then determine the compliance rate by obtaining multiple service data points from the forwarding hardware of the switch and calculating the compliance rate based on the difference between the multiple service data points and the sampling interval.

[0022] In other variations, the system may issue queries to the forwarding hardware and obtain business data points in response to the queries.

[0023] In other variations, the system may obtain a request for a compliance rate, obtain a first service data point at a requested time, and obtain a second service data point at a sampling interval.

[0024] In other variations, the number of the plurality of business data points may be two.

[0025] In other variations, the corresponding traffic data point is a cumulative data unit count for interfaces associated with a plurality of traffic policing filters.

[0026] In a variation of this embodiment, the selection strategy may include selection based on one or more of: maximum token allocation frequency, minimum token allocation frequency, mean of token allocation frequencies, median of token allocation frequencies, and weighted average of token allocation frequencies.

[0027] In a variation of this embodiment, the system may be configured with multiple classifier policies. Further, a sampling interval may be associated with a first classifier policy. The system may then select a second sampling interval from the token allocation frequencies of one or more traffic supervision filters of a second classifier policy.

[0028] In a variation of this embodiment, if the sampling interval is less than the low watermark, the system may mark the low watermark as the sampling interval. On the other hand, if the sampling interval is greater than the high watermark, the system may mark the high watermark as the sampling interval.

[0029] In a variation of this embodiment, the plurality of traffic policing filters may include a hierarchical serial traffic policy filter associated with a plurality of token buckets. The representative time interval of the hierarchical serial traffic policy filter used to determine the sampling interval may correspond to the sum of the time intervals associated with the plurality of token buckets.

[0030] In a variation of this embodiment, the plurality of traffic policing filters may include hierarchical parallel traffic policy filters associated with a plurality of token buckets. Then, the representative time interval of the hierarchical serial traffic policy filter used to determine the sampling interval may correspond to the maximum time interval associated with the plurality of token buckets.

[0031] Embodiments described herein solve the problem of determining compliance of a classifier policy of a switch by: (i) determining a corresponding time interval based on a rate limiting parameter associated with the corresponding classifier policy; and (ii) determining an execution rate based on a sampling interval derived from the time interval. Examples of execution rates may include, but are not limited to, compliance rates, exceedance rates, and violation rates. For example, the compliance rate may indicate the degree to which the rate limiting parameter meters traffic from the switch. By determining the execution rate based on the sampling interval, the switch can effectively provide the execution rate to an administrator.

[0032] The traffic management system of the switch can use multiple classifier strategies to manage traffic flows. The classifier strategy can promote one or more traffic meters (or traffic regulators) that can manage the maximum rate of traffic flows based on token buckets (or buckets). Based on the token bucket, the system can determine whether the traffic associated with the meter meets the defined bandwidth limits and burst limits (measurement of traffic changes). The system can measure traffic based on data units (e.g., a predetermined number of bytes or packets). The system can periodically allocate tokens to the token bucket. The rate at which the system allocates tokens can indicate the average data rate of the meter. Moreover, the depth or size of the token bucket (i.e., the number of tokens that the token bucket can accommodate) can indicate the burstiness of the traffic.

[0033] The token bucket can be associated with three parameters: mean rate or information rate, burst size, and time interval. The information rate can be determined as (burst size / time interval) and indicates how much data can be forwarded per unit time on average (e.g., average data rate). The burst size can indicate the number of data units per burst, such as the number of bits or bytes (e.g., the amount of traffic that can be sent per unit time). The time interval can indicate the duration or time scale of each burst. The system can allocate tokens based on the token generation rate. Typically, the system can allocate a burst size number of tokens for each time interval. If a token arrives when the bucket is full, the system can discard the token.

[0034] When a packet of n units (such as bytes) arrives, if there are at least n tokens in the bucket, the system can remove n tokens from the bucket and forward the packet. On the other hand, if there are fewer than n tokens available in the bucket, the system may consider the packet non-compliant and store the packet in a buffer (or discard the packet). For packets that do not comply, the system does not remove any tokens from the bucket. With the prior art, if an administrator issues a request to a switch to check compliance with a classifier policy, the system can query the underlying switch hardware (e.g., an application-specific integrated circuit (ASIC)). In response, the switch hardware can report cumulative data unit counts (e.g., byte or packet counts) in one or more categories. The byte count can indicate the number of bytes transmitted associated with the classifier policy. Categories can include compliant data unit counts below the information rate, data unit counts exceeding the information rate but below the peak rate, and data unit counts exceeding the peak rate. However, cumulative data unit counts may not provide meaningful insights into compliance with classifier policies.

[0035] Based on the empirical analysis of the traffic information in different network configurations, the system can use a set of rules for burst size. One of the rules can indicate that the amount of time that a traffic burst should be allowed to use the full line rate should not be less than five milliseconds (ms). Another rule can indicate that the size limit of a traffic burst should not be less than ten times the maximum transmission unit (MTU). For example, if a classifier policy for Ethernet is defined, the MTU can be 1500 bytes. Since the token bucket may allow full line rate access for such a small MTU for 5 milliseconds, sampling over a long period of time may not be necessary and the computational effort is large.

[0036] On the other hand, if a classifier policy is defined for the Transmission Control Protocol (TCP), the MTU may be 64 kilobytes. Therefore, the size limit of the bursty traffic may be large. Therefore, the token bucket may allow bursts that take at most a few seconds. In order to accurately represent the compliance of a token bucket that allows such large bursts, the system may need to sample over a long period of time. As a result, different scenarios may require compliance rates to adapt to different sampling intervals. Depending on the burst size of the token bucket, the system may need to report compliance rates over short or long periods of time. Therefore, it may be challenging to accurately report compliance rates with low computational overhead.

[0037] To address this problem, the system can calculate and report the current service rate based on the cumulative data unit count obtained from the switch hardware at the sampling interval. The cumulative data unit count can indicate the number of bytes transmitted from the interface since the initial transmission. Typically, the administrator configures the information rate and burst size for the corresponding token bucket associated with the instrument of the classifier policy. The system can facilitate an adaptive instrument execution rate sampling method by determining the sampling interval (e.g., time difference) based on the user configuration. The system can sample the cumulative data unit count from the switch hardware based on the sampling interval. For example, consecutive cumulative data unit counts can be separated in time by the sampling interval. Therefore, the resulting execution rate can accurately reflect the current moment, where the response time is fast and the computational overhead is low. In this way, the system can provide an execution rate that can indicate relevant and meaningful service rate measurements to the administrator.

[0038] During operation, when an administrator configures the information rate and burst size for a corresponding token bucket associated with a meter of a classifier policy, the system can determine the time interval of the token bucket based on the configured parameters. The time interval can indicate the duration of a traffic burst. In this way, the system can determine the time interval of the corresponding token bucket of the switch at configuration time. As a result, when traffic starts to arrive, the switch can easily use the token bucket for metering. In some embodiments, the system can determine the time interval as (burst size / information rate) and use the time interval as the sampling interval. Since the sampling interval is determined based on the configuration of the token bucket, sampling based on the sampling interval can accommodate short traffic bursts or long traffic bursts.

[0039] For example, if the administrator configures short bursts (e.g., services that may peak in a short period of time), the corresponding sampling interval can also be short. The system can then calculate execution rates such as compliance rates by using the sampling interval and report back the compliance rate with a shorter wait time. On the other hand, if the administrator configures long bursts (e.g., service bursts that may last for a long period of time), the corresponding sampling interval can accommodate the largest burst size. The system can then calculate the compliance rate by using the sampling interval and report back the compliance rate without incurring long wait times. In order to ensure that the sampling interval remains within reasonable limits (e.g., based on empirical data), the system can maintain a low watermark (e.g., a duration of 3 milliseconds) and a high watermark (e.g., a duration of 5 seconds) for the sampling interface. If the calculated value is lower than the low watermark or higher than the high watermark, the system can select the low watermark value or the high watermark value as the sampling interval, respectively.

[0040] In order to reduce the overhead of the computing resources and hardware resources of the switch, the system can query the cumulative data unit count a predetermined number of times separated by a sampling interval. A query can be issued to the underlying switch hardware, which can then respond with the cumulative data unit count at the query time. In some embodiments, the system can issue a query twice. When the administrator requests a compliance rate, the system can issue an initial query. Then, the system can issue a second query after the sampling interval. Based on the two cumulative data unit counts obtained from the two queries, the system can determine the compliance rate as (Δ bytes / sampling interval). Δ bytes can indicate the difference between the cumulative bytes. Since the query is issued twice, the overhead of the computing resources and hardware resources of the switch can be very low. Furthermore, when the administrator is not monitoring the compliance rate, the system does not use hardware resources.

[0041] In order to minimize resource utilization and latency, the system can facilitate parallelization of multiple meters or supervisors across classifier policies. If multiple meters are configured for the classifier policy, the system can obtain the time intervals of all token buckets and select a representative time interval based on a selection policy. The selection policy can indicate a selection based on one or more of the following: a maximum time interval value, a minimum time interval value, a mean time interval value, a median time interval value, and a weighted average of time interval values. For example, if the system selects the maximum time interval, the system can calculate the compliance rate based on the maximum time interval as the sampling interval of the meter group in the classifier policy. If the switch is equipped with multiple line cards or stack components, the sampling intervals of all line cards or stack components are selected based on the selection policy, thereby achieving parallelization in the switch.

[0042] In the present disclosure, the term "switch" is used in a general sense, and it can refer to any stand-alone or structural switch operating in any network layer. "Switch" should not be interpreted as limiting the embodiments of the present invention to layer 2 networks. Any device that can forward traffic to an external device or other switch can be referred to as a "switch". Any physical or virtual device that can forward traffic to a terminal device (e.g., a virtual machine or switch operating on a computing device) can be referred to as a "switch". Examples of "switch" include, but are not limited to, a layer 2 switch, a layer 3 router, a routing switch, a component of a Gen-Z network, or a structural switch comprising multiple similar or heterogeneous smaller physical and / or virtual switches.

[0043] The term "packet" refers to a group of bits that can be transmitted together across a network. "Packet" should not be interpreted as limiting embodiments of the present invention to layer 3 networks. "Packet" may be replaced by other terms that refer to groups of bits, such as "message," "frame," "cell," "datagram," or "transaction." Further, the term "port" may refer to a port that can receive or transmit data. "Port" may also refer to hardware, software, and / or firmware logic that can facilitate the operation of the port.

[0044] Network Architecture

[0045] Figure 1A An exemplary network that promotes efficient instrumentation compliance in switches according to an embodiment of the present application is illustrated. Network 100 includes switches 102, 104, and 106. Network 100 may also include an access device 108 coupled to switch 104. Access device 108 may allow a user 120 (e.g., a network administrator) to configure switch 104. In some embodiments, network 100 is a Gen-Z network, and corresponding switches of network 100 (such as switch 104) are Gen-Z components. In this scenario, communication between switches in network 100 is based on memory semantic communication. The corresponding packets forwarded via network 100 may be referred to as transactions, and the corresponding data units may be micro slices. In some other embodiments, network 100 may be an Ethernet, InfiniBand, or other network, and may use corresponding communication protocols, such as Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols.

[0046] The traffic management system 140 of the switch 104 can use multiple classifier strategies to manage traffic flows. The classifier strategy can promote the traffic meter 110 (or traffic regulator) that can manage the maximum rate of traffic flows based on the token bucket 114. Based on the token bucket 114, the system 140 can determine whether the traffic managed by the meter 110 meets the bandwidth and burst limits defined by the token bucket 114. The system 140 can measure traffic based on data units. The system 140 can periodically allocate tokens to the token bucket 114. The token rate 116 can be the rate at which the system 140 allocates tokens to the token bucket 114 and indicates the average data rate of the meter 110. Moreover, the depth or size of the token bucket 114 can indicate the burstiness of the traffic. The user 120 can configure the information rate 126 and burst size 126 of the token bucket 114.

[0047] The time interval 122 may be associated with the token bucket 114 such that the information rate 126 = (burst size 124 / time interval 122). The time interval 122 may indicate the duration or time quantum of each burst. Typically, the system 140 may allocate a burst size 124 (i.e., the number of tokens) of tokens for each time interval 122 (i.e., the duration). If a token arrives when the token bucket 114 is full, the system 140 may discard the token. When a packet 132 of n data units arrives at the switch 104, if there are at least n tokens in the token bucket 114, the system 140 may remove n tokens from the token bucket 114 and forward the packet 132. On the other hand, if there are less than n tokens available in the token bucket 114, the system 140 may treat the packet 132 as a non-compliant packet and store the packet 132 in a buffer (or discard the packet). If the packet 132 is a non-compliant packet, the system 132 may not remove any tokens from the token bucket 114.

[0048] In order to monitor bandwidth usage and determine the extent to which traffic complies with traffic meter 110, user 120 may issue a request 172 from access device 108 to switch 104 to check the execution rate of traffic meter 110. Examples of execution rates may include, but are not limited to, compliance rates, exceedance rates, and violation rates associated with meter 110. However, due to the wide variation of rate limiting parameters and sampling time periods, traditional rate reports may be inaccurate, slow to reflect traffic changes, or have significant overhead due to constant sampling from switch hardware. To address this issue, system 140 may determine a time interval 122 based on rate limiting parameters, such as burst size 124 and information rate 126 associated with traffic meter 110. In some embodiments, time interval 122 may be calculated as (burst size 124 / information rate 126). System 140 may then determine an execution rate, such as a compliance rate 174, based on a sampling interval 130 derived from time interval 122. By determining compliance rate 174 based on a sampling interval, switch 104 may effectively provide compliance rate 174 to user 120. Using the sampling interval, switch 104 may also determine an exceedance rate or a violation rate.

[0049] Since the time interval 122 indicates the duration of a burst of traffic and is determined based on the configuration of the token bucket 114, the time interval 122 can be a representative time interval based on which the compliance rate 174 can be determined. Thus, the system 140 can use the time interval 122 as a sampling interval 130 for determining the compliance rate 174. The compliance rate 174 determined based on the sampling interval 130 can accommodate short bursts or long bursts of traffic. For example, if the user 120 configures the token bucket 114 for short bursts, where the values ​​of the burst size 124 and / or the information rate 126 can be small, the time interval 122 can also be short. Then, the system 140 can calculate the compliance rate by using the time interval 122 as the sampling interval 130 and report back the compliance rate 174 with low latency.

[0050] On the other hand, if the user 120 configures long bursts, where the values ​​of the burst size 124 and / or the information rate 126 can be large, the sampling interval 130 can accommodate the largest burst size. However, since the sampling interval 130 corresponds to the time interval 122, the system 140 can calculate and report the response rate 174 without incurring long wait times. To ensure that the sampling interval 130 remains within reasonable limits, the system 140 can maintain a low watermark (e.g., a duration of 3 milliseconds) and a high watermark (e.g., a duration of 5 seconds) for the sampling interface. If the time interval 122 is below the low watermark or above the high watermark, the system 140 can select the low watermark value or the high watermark value, respectively, as the sampling interval 130.

[0051] Figure 1BAn exemplary switch structure that promotes efficient meter compliance in a switch according to an embodiment of the present application is illustrated. The switch 104 can be equipped with a processor 142 (e.g., a central processing unit of the switch 104) and switch hardware 144 (e.g., a set of ASIC chips that facilitate packet forwarding). The switch 104 can maintain different service meters for different categories of services. For example, if a classifier policy is defined for transport layer services using TCP, the system 140 can maintain a set of service meters 110, 150, and 160 for different types of services that may use TCP (e.g., voice, video, and network services). The service meters 110, 150, and 160 can respectively maintain token generators 112, 152, and 162, which can generate tokens for token buckets 114, 154, and 164, respectively.

[0052] With the prior art, if the user 120 issues a request to the switch 104 to check the compliance of the service meters 110, 150, and 160, the system 140 can query the underlying switch hardware 144. In response, the switch hardware 144 can report the cumulative data unit count. However, the cumulative data unit count may not provide meaningful insights about service compliance. For example, if the compliance rate is calculated as an average rate based on the total data unit count and the total elapsed time of the service meter 110, the average rate does not reflect the service fluctuations in the network 100. On the other hand, the compliance rate of the service meter 110 can be determined as the current (or most recent) service rate within a short period of time (e.g., microseconds). However, the service rate within a short period of time may vary from the full line rate to almost zero. Therefore, the current rate may not reflect the burstiness of the service in the network 100.

[0053] To combine the long-term average rate and the short-term burst size, some approaches may rely on frequent sampling from the switch hardware 144 and calculate a weighted (or decaying) average of the sampled data unit counts. However, such a scheme requires periodic sampling via the processor 142, which may result in significant overhead on the switch hardware 144 and high utilization of the processor 142. Therefore, depending on the burst size of the token bucket (e.g., the burst size 124 of the token bucket 114), the system 140 may need to report the compliance rate over a short period of time or a long period of time. Alternatively, the system 140 may need to frequently query the switch hardware 144 via the processor 142 (e.g., using interrupts) and result in significant overhead on the processor 142 and the switch hardware 144. Therefore, it is challenging to accurately report the compliance rate 174 with low computational overhead.

[0054] To address this issue, the system 140 can calculate and report the current traffic rate based on the cumulative data unit count, which is obtained from the switch hardware 144 based on the sampling interval 174. The cumulative byte count can indicate the number of bytes metered based on the traffic meters 110, 150, and 160. When the user 120 configures the information rate 126 and the burst size 124 for the token bucket 114, the system 140 can determine the time interval 122 for the token bucket 114. The system 140 can determine the time interval 122 as (burst size 124 / information rate 126). In the same manner, the system 140 can determine the time intervals 158 and 168 for the token buckets 154 and 164, respectively. Then, the token generators 112, 152, and 162 can generate tokens of burst sizes 124, 156, and 166 for the time intervals 122, 158, and 168, respectively. Because system 140 can determine time intervals 122, 158, and 168 at configuration time, switch 104 can begin forwarding traffic whenever the corresponding class of traffic is likely to arrive at switch 104.

[0055] Assume that the switch 104 receives a packet 134 belonging to a traffic class metered by the traffic meter 110. The system 140 can then determine whether there are a sufficient number of tokens in the token bucket 114. If the available tokens 134 in the token bucket 114 are sufficient for the packet, the system 140 can remove the tokens from the token bucket 114 and forward the packet 134. The switch 104 can also receive a packet 136 belonging to a traffic class metered by the traffic meter 150. The system 140 can then determine whether there are a sufficient number of tokens in the token bucket 154. If the available number of tokens in the token bucket 114 is insufficient for the packet 136, the system 140 can consider the packet 136 to be a non-compliant packet. The system 140 can then buffer or discard the packet 136 without removing the tokens from the token bucket 154.

[0056] For token bucket 114, time interval 122 may indicate the duration of a traffic burst whose size corresponds to burst size 124 at most. Similarly, for token buckets 154 and 164, time intervals 158 and 168 may indicate the duration of a traffic burst whose size corresponds to burst size 156 and 166 at most, respectively. System 140 may facilitate an adaptive instrument compliance rate sampling method by determining a sampling interval based on time intervals 122, 158, and 168. System 140 may sample cumulative data unit counts from switch hardware 144 based on a sampling interval. For example, consecutive cumulative data unit counts obtained from switch hardware 144 may be separated in time by a sampling interval. Therefore, the compliance rate 174 reported by system 140 may accurately reflect the current moment with a fast response time and low computational overhead. In this way, system 140 may provide compliance rates to user 120 that may indicate relevant and meaningful traffic rate measurements.

[0057] To reduce processing overhead on the processor 142 and the switch hardware 144 of the switch 104, the system 140 may query the accumulated data unit count a predetermined number of times separated by a sampling interval. Figure 2A An exemplary selection of a sampling interval for determining compliance of a service meter associated with a classifier policy in a switch according to an embodiment of the present application is illustrated. After determining the time intervals 122, 158, and 168, the system 140 may select the time interval as the sampling interval 210 based on a selection policy. The selection policy may indicate a selection based on one or more of the following: a maximum time interval value, a minimum time interval value, a mean time interval value, a median time interval value, and a weighted average of time interval values. In some embodiments, the system 140 may select the maximum time interval value as the sampling interval 210. If the time interval 158 has a maximum value among the time intervals 122, 158, and 168, the system 140 may select the time interval 158 as the sampling interval 210.

[0058] During operation, the user 120 may send a request 202 to the switch 104 to obtain the execution rate of the classifier policy. Typically, the user 120 may issue such a request after the service meters 110, 150, and 160 remain operational for a period of time. The user 120 may use a user interface 200 of the access device 108 to issue the request 202. Examples of the interface 200 may include, but are not limited to, a text interface (e.g., a command line interface or CLI), a graphical user interface (GUI), a virtual or augmented reality interface, an interface based on voice commands, and an interface based on gestures. Upon receiving the request 202, the system 140 may issue a query to the switch hardware 144 to obtain a predetermined number of cumulative data unit counts. In some embodiments, the predetermined number of times the query is issued is twice.

[0059] When the switch 104 receives the request 202, the system 140 may issue an initial query 204. The switch hardware 144 may then respond with the cumulative data unit count 212. The system 140 may issue a second query 206 after a period of the sampling interval 210. The switch hardware 144 may then respond with the cumulative data unit count 214. In this way, the system 140 may obtain the cumulative data unit counts 212 and 214 from the two queries 204 and 206, respectively. The system 140 may determine the execution rate 222 as (Δ bytes / sampling interval 210). The execution rate 222 may include one or more of the following: a compliance rate, an exceedance rate, and a violation rate. Δ bytes may indicate a difference determined by (cumulative data unit count 214-cumulative data unit count 212). Since the system 140 may issue two queries 204 and 206, the overhead on the processor 142 and the switch hardware 144 may be low. Furthermore, when the user 120 is not monitoring the compliance rate, the system 140 does not determine the compliance rate using the processor 142 and the switch hardware 144. Using the sampling interval 210, the system 140 may also determine an exceedance rate or a violation rate (ie, other types of enforcement rates).

[0060] Figure 2B An exemplary selection of time intervals for determining compliance of service meters associated with different classifier policies in a switch according to an embodiment of the present application is illustrated. In order to minimize resource utilization and latency, the system 140 can facilitate parallelization of multiple meters or supervisors across classifier policies. The user 120 can configure multiple classifier policies 252 and 254 of the switch 104. For example, the classifier policies 252 and 254 can be defined for TCP and UDP, respectively. Assume that service meters 110, 150, and 160 are defined by the classifier policy 252. On the other hand, the service meter 230 is defined by the classifier policy 254. Based on the corresponding rate limiting parameters, the system 140 can determine the time intervals 122, 158, and 168 for the classifier policy 252, and the time interval 232 for the classifier policy 254.

[0061] Since the plurality of traffic meters 110, 150, and 160 are configured for the classifier strategy 252, the system 140 can select the representative time interval 158 as the sampling interval 210 based on the selection strategy, such as in combination with Figure 2AAs described. On the other hand, since the classifier policy 254 includes the traffic meter 230, the system 140 can select the time interval 232 as the sampling interval 220. Further, if the switch 104 is equipped with multiple line cards or stack components, the sampling interval is selected for all line cards or stack components based on the selection policy, thereby achieving parallelization in the switch 104. The system 140 can determine a separate compliance rate for each of the classifier policies 252 and 254. To determine each compliance rate, the system 140 can issue two queries to the switch hardware 144. However, to reduce overhead, the system 140 can use the same initial query 204 when receiving the request 202. The switch hardware 144 can then respond with the accumulated data unit count 212.

[0062] Assume that the time interval 232 is less than the time interval 158. Therefore, the sampling interval 220 can be less than the sampling interval 210. After the period of the sampling interval 220 used to determine the compliance rate, the system 140 can issue a subsequent query 208 after the period of the sampling interval 220 of the classifier policy 254. Then, the switch hardware 144 can respond with the cumulative data unit count 216. The system 140 can determine the execution rate 224 based on the difference between the cumulative data unit counts 216 and 212 and the sampling interval 220. The execution rate 224 can include one or more of the following: a compliance rate, an exceedance rate, and a violation rate. The system 140 can provide the execution rate 224 to the user 120 (e.g., via the interface 200). Subsequently, the system 140 can issue a subsequent query 206 of the classifier policy 254 after the period of the sampling interval 210 used to determine the compliance rate. Then, the system 140 can determine the execution rate 222 based on the difference between the cumulative data unit counts 214 and 212 and the sampling interval 210. Thus, system 140 may use cumulative byte count 212 to determine both execution rates 222 and 224. Because system 140 may issue queries 204, 206, and 208, the overhead on processor 142 and switch hardware 144 may remain low.

[0063] Figure 2C An exemplary configuration of service meters in different classifier policies in a switch according to an embodiment of the present application is illustrated. User 120 can configure classifier policies 252 and 254 based on interface 200. In this example, classifier policy 252 can include service meters (or service supervision filters) 110, 150, and 160; and classifier policy 254 can include service meter 230. Each service meter can be implemented as a token bucket in switch 104. In other words, system 140 can allocate corresponding token buckets for all four service meters, regardless of their association with classifier policies or whether they are used with other service meters.

[0064] The system 140 may then determine a time interval for each token bucket. The system 140 may compare the time intervals calculated for the token buckets and select the maximum time interval within the classifier policy to determine the compliance rate. Since the time interval may be determined as a burst size / information rate, the system 140 may determine that the service meter 150 (e.g., configured with a burst size of 1000 and an information rate of 10 Kbps) may have the maximum time interval in the classifier policy 252. Therefore, the system 140 may determine the execution rate 222 based on the time interval 158 of the service meter 150 in the classifier policy 252. On the other hand, the classifier policy 254 may have only one service meter 230 (e.g., configured with a burst size of 1000 and an information rate of 1000 Kbps), and the system 140 may consider the time interval 232 of the service meter 230 as the maximum time interval in the classifier policy 252. Therefore, the system 140 may determine the execution rate 224 based on the time interval 232 of the service meter 230 in the classifier policy 252.

[0065] Figure 3A An exemplary selection of sampling intervals for determining compliance with a hierarchical serial traffic meter in a switch according to an embodiment of the present application is illustrated. The switch 104 may include a hierarchical serial traffic meter 300, which may include a plurality of serial token buckets 302, 304, and 306 (e.g., n serial token buckets, such as leaky buckets) associated with burst sizes 312, 314, and 316, respectively. Herein, the burst size 312 may be a committed burst size, and the burst sizes 314 and 316 may be excess burst sizes. A token generator 318 may generate tokens for the token bucket 302 based on an information rate 318. Excess tokens from the token bucket 302 are allocated to the token bucket 304. The allocation of excess tokens is propagated to subsequent token buckets, such as the token bucket 306. Typically, the burst sizes 312, 314, and 316, as well as the information rate 318, may be configured by a user.

[0066] The system 140 may determine time intervals 322, 324, and 326 for token buckets 302, 304, and 306, respectively, such as in combination with Figure 1BAs described. For example, the time interval 322 of the token bucket 302 can be calculated as (burst size 312 / information rate 318). Similarly, the time intervals 324 and 326 can be calculated as (burst size 314 / information rate 318) and (burst size 316 / information rate 318), respectively. The system 140 can then determine the meter time interval 320, which can be a representative time interval for determining the sampling interval for the meter 300. The time interval 320 can be calculated as the sum of n time intervals associated with the meter 300. In this example, the time interval 320 can be calculated as the sum of the time intervals 322, 324, and 326. Subsequently, the system 140 can use the time interval 320 to determine the performance rate of the meter 300, such as the compliance rate, the exceedance rate, and / or the violation rate.

[0067] Figure 3B An exemplary selection of sampling intervals for determining compliance with a hierarchical parallel service meter in a switch according to an embodiment of the present application is illustrated. The switch 104 may include a hierarchical parallel service meter 330, which may include a plurality of parallel token buckets 332, 334, and 336 (e.g., m parallel token buckets), which are associated with burst sizes 342, 344, and 346, respectively. Due to parallelism, the token buckets 332, 334, and 336 may be associated with information rates 352, 354, and 356, respectively. Herein, the burst size 342 and the information rate 352 may be a committed burst size and a committed information rate, respectively. The burst sizes 344 and 346 may be peak burst sizes, and the information rates 354 and 356 may be peak information rates. The token generator 338 may allocate tokens to the token buckets based on the corresponding burst sizes and information rates of the token buckets 332, 334, and 336. Typically, the burst size and information rate may be configured by the user.

[0068] System 140 may determine time intervals 362, 364, and 366 for token buckets 332, 334, and 336, respectively, such as in combination with Figure 1BAs described. For example, the time interval 362 of the token bucket 332 can be calculated as (burst size 342 / information rate 352). Similarly, the time intervals 364 and 366 can be calculated as (burst size 344 / information rate 354) and (burst size 346 / information rate 356), respectively. The system 140 can then determine the meter time interval 360, which can be a representative time interval for determining the sampling interval for the meter 330. The time interval 360 can be calculated as the maximum time interval among the m time intervals associated with the meter 330. In this example, the time interval 360 can be calculated as the maximum time interval among the time intervals 362, 364, and 366. Subsequently, the system 140 can use the time interval 360 to determine the execution rate of the meter 330, such as the compliance rate, the exceedance rate, and / or the violation rate.

[0069] Figure 3C An exemplary selection of sampling intervals for determining compliance of heterogeneous traffic meters associated with a classifier policy in a switch according to an embodiment of the present application is illustrated. In this example, a user 120 can configure a heterogeneous classifier policy 310 for a switch 104. The classifier policy 310 can include a hierarchical serial traffic meter 300 and a hierarchical parallel traffic meter 330. In addition, the classifier policy 310 can also include a non-hierarchical traffic meter 390. Assume that the system 140 has determined a time interval 392 for the traffic meter 390. Based on the time intervals 320, 360, and 392, the system 140 can select a time interval as a sampling interval 370 for the classifier policy 310 based on a selection policy.

[0070] The selection strategy may indicate a selection based on one or more of the following: a maximum time interval value, a minimum time interval value, a mean time interval value, a median time interval value, and a weighted average of time interval values. In some embodiments, the system 140 may select the maximum time interval value as the sampling interval 370. If the time interval 320 has the maximum time interval among the time intervals 320, 360, and 392, the system 140 may select the time interval 320 as the sampling interval 370. When receiving a request 382 for an execution rate for the classifier strategy 310, the system 140 may obtain a cumulative data unit count from the switch 144 based on the sampling interval 370. Then, the system 140 may calculate an execution rate 384 and send it to the access device 108. The execution rate 384 may include one or more of the following: a compliance rate, an excess rate, and a violation rate. It should be noted that the cumulative data unit count may include a data unit count associated with a corresponding token bucket of a corresponding service meter in the classifier strategy 310.

[0071] operate

[0072] Figure 4A flow chart illustrating a process of a traffic management system of a switch for determining a sampling interval of a classifier policy according to an embodiment of the present application is presented. During operation, the system may obtain a burst size and an information rate of a traffic meter of a classifier policy (operation 402) and determine a time interval based on the burst size and the information rate (operation 404). The system may also determine a token rate based on the time interval, the burst size, and the information rate (operation 406). For example, the token rate may indicate a token generation rate of a burst size number of tokens per time interval. The system may then configure a token bucket associated with the traffic meter based on the time interval, the burst size, and the information rate (operation 408). The system may check whether the classifier policy is configured (i.e., the configuration is complete) (operation 410). If the classifier policy is not configured, the system may continue to obtain a burst size and an information rate of a traffic meter of the classifier policy (operation 402).

[0073] Figure 5A A flow chart illustrating a process of a business management system for a switch that facilitates compliance information for a business meter associated with a classifier policy according to an embodiment of the present application is presented. During operation, the system may receive a request for a compliance rate (operation 502) and determine a sampling interval for a corresponding classifier policy (operation 504). The system may then issue an initial query to the switch hardware to obtain an initial cumulative data unit count (operation 506). The system may select a classifier policy based on the sampling interval (e.g., based on an ascending order) (operation 508). The system may then issue a subsequent query to the switch hardware after the sampling interval associated with the classifier policy to obtain a subsequent cumulative data unit count (operation 510). It should be noted that the system may also use the sampling interval to determine other types of execution rates, such as a violation rate or an exceedance rate.

[0074] The system may then determine the compliance rate for the classifier strategy based on the corresponding cumulative data unit count and the sampling interval (operation 512). Subsequently, the system may determine whether the compliance rate has been determined for all classifier strategies (operation 514). If the compliance rate has not been determined for all classifier strategies, the system may proceed to select the next classifier strategy (operation 508). On the other hand, if the compliance rate has been determined for all classifier strategies, the system may provide a response indicating the compliance rate for the corresponding classifier strategy (operation 516).

[0075] Figure 5BA flow chart illustrating a process of a business management system for determining a sampling interface for a switch for determining compliance information according to an embodiment of the present application is presented. During operation, the system may select a classifier policy (operation 552) and select a maximum time interval associated with a business meter in the classifier policy (operation 554). The system may then determine whether the selected time interval is greater than a high watermark (operation 556). If the selected time interval is not greater than the high watermark (operation 556), the system may also determine whether the selected time interval is less than a low watermark (operation 558). If the selected time interval is not less than the low watermark (operation 556), the system may record the selected time interval as a sampling interval for the classifier policy (operation 560).

[0076] On the other hand, if the selected time interval is greater than the high watermark, the system may mark the high watermark as the sampling interval for the classifier strategy (operation 564). Similarly, if the selected time interval is less than the low watermark, the system may mark the low watermark as the sampling interval for the classifier strategy (operation 566). After indicating the sampling intervals for the classifier strategies (operation 560, 564, or 566), the system may determine whether the sampling intervals have been determined for all classifier strategies (operation 562). If the sampling intervals have not been determined for all classifier strategies, the system may proceed to select the next classifier strategy (operation 552).

[0077] Exemplary switch system

[0078] Figure 6 An exemplary switch supporting efficient instrument compliance according to an embodiment of the present application is illustrated. In this example, the switch 600 includes a plurality of communication ports 602, a packet processor 610, a flow control logic block 630, a compliance logic block 640, and a storage device 650. The switch 600 may also include switch hardware 660 (e.g., processing hardware of the switch 600, such as its ASIC chip), which includes information based on which the switch 600 processes the packet (e.g., determines the output port of the packet). The packet processor 610 extracts and processes header information from the received packet. The packet processor 610 may identify a switch identifier (e.g., a media access control (MAC) address and / or an IP address) associated with the switch 600 in the header of the packet.

[0079] The communication port 602 may include an inter-switch communication channel for communicating with other switches and / or user equipment. The communication channel may be implemented via a conventional communication port and based on any open or proprietary format. The communication port 602 may include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header. The communication port 602 may also include one or more IP ports capable of receiving IP packets. The IP port may receive IP packets and may be configured with an IP address. The packet processor 610 may process Ethernet frames and / or IP packets. The corresponding ports of the communication port 602 may be used as inlet ports and / or outlet ports.

[0080] The switch 600 may maintain a database 652 (e.g., in a storage device 650). The database 652 may be a relational database and may run on one or more DBMS instances. The database 652 may maintain information associated with corresponding classifier policies in the database 652. The flow control logic block 630 and the conformance logic block 640 may facilitate the operation of the system 140.

[0081] The flow control logic block 630 may include an interval logic block 632, a token logic block 634, and a control logic block 636. The interval logic block 632 may determine a corresponding time interval of a service meter of a corresponding classifier policy. The interval logic block 632 may also determine a sampling interval of a corresponding classifier policy. The token logic block 634 may generate a token for a corresponding token bucket of a corresponding service meter based on the time interval and the configured parameters of the service meter. The control logic block 636 may determine whether to forward a packet based on the number of available tokens in the corresponding token bucket.

[0082] The compliance logic block 640 may include a query logic block 642, a sampling logic block 644, and a notification logic block 646. The query logic block 642 may query the switch hardware 660 for service information, such as a cumulative data unit count of a classifier policy. The sampling logic block 644 may determine a sampling interval for a corresponding classifier policy. The sampling logic block 644 may also determine a time difference between queries of the switching hardware 660 based on the sampling interval. The calculation logic block 646 may determine a compliance rate based on the sampling interval and the cumulative data unit count obtained based on the query. The calculation logic block 646 may also provide the compliance rate to an administrator.

[0083] The data structures and codes described in this detailed description are typically stored on a computer-readable storage medium, which can be any device or medium that can store code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic storage devices, and optical storage devices (such as magnetic disks, tapes, CDs (compact disks), DVDs (digital versatile disks or digital video disks), or other media capable of storing computer-readable media now known or later developed).

[0084] The methods and processes described in the detailed description may be embodied as code and / or data, which may be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on a computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and codes and stored in the computer-readable storage medium.

[0085] The methods and processes described herein may be performed by and / or included in hardware modules or devices. These modules or devices may include, but are not limited to, application specific integrated circuit (ASIC) chips, field programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software modules or code segments at specific times, and / or other programmable logic devices now known or later developed. When the hardware modules or devices are activated, they execute the methods and processes contained therein.

[0086] The foregoing descriptions of the embodiments of the present invention are for illustration and description purposes only. They are not intended to be exhaustive or to limit the present disclosure. Therefore, many modifications and variations will be apparent to those skilled in the art. The scope of the present invention is defined by the appended claims.

Claims

1. A method for facilitating data transmission in a switch, the method comprising: Obtain one or more configuration parameter sets for a plurality of traffic policing filters of the switch, wherein the traffic policing filters correspond to token buckets, and wherein the number of tokens in the token buckets indicates whether to forward packets associated with the traffic policing filters; determining a token allocation frequency for the plurality of traffic policing filters based on the one or more sets of configuration parameters; selecting a sampling interval from the token allocation frequency based on a selection strategy; as well as An execution rate for the plurality of traffic policing filters is determined based on the sampling interval. 2 . The method according to claim 1 , wherein a configuration parameter set in the one or more configuration parameter sets comprises an information rate and a burst size of a token bucket.

3. The method of claim 1 , wherein the execution rate comprises a compliance rate for the plurality of traffic policing filters, and wherein determining the compliance rate further comprises: Acquire a plurality of service data points from forwarding hardware of the switch; as well as The compliance rate is calculated based on the difference between the plurality of business data points and the sampling interval.

4. The method according to claim 3, further comprising: issuing a query to the forwarding hardware; as well as A business data point is obtained in response to the query.

5. The method according to claim 3, further comprising: A request for the compliance rate is obtained, wherein a first traffic data point is obtained at a time of the request, and wherein a second traffic data point is obtained at the sampling interval.

6. The method of claim 3, wherein the corresponding traffic data point is a cumulative data unit count of interfaces associated with the plurality of traffic policing filters.

7. The method of claim 1, wherein the switch is configured with a plurality of classifier policies, and wherein the sampling interval is associated with a first classifier policy; and The method further comprises: The second sampling interval is selected from token allocation frequencies of one or more traffic policing filters of the second classifier policy.

8. The method according to claim 1, further comprising: In response to determining that the sampling interval is less than a low watermark, marking the low watermark as the sampling interval; as well as In response to determining that the sampling interval is greater than a high watermark, marking the high watermark as the sampling interval.

9. The method of claim 1, wherein the selection strategy comprises selection based on one or more of: a maximum token allocation frequency, a minimum token allocation frequency, a mean of the token allocation frequencies, a median of the token allocation frequencies, and a weighted average of the token allocation frequencies.

10. The method of claim 1, wherein the plurality of traffic supervision filters comprises a hierarchical serial traffic policy filter associated with a plurality of token buckets, and wherein a representative time interval of the hierarchical serial traffic policy filter used to determine the sampling interval corresponds to a sum of time intervals associated with the plurality of token buckets.

11. The method of claim 1 , wherein the plurality of traffic supervision filters comprises a hierarchical parallel traffic policy filter associated with a plurality of token buckets, and wherein a representative time interval of the hierarchical serial traffic policy filter used to determine the sampling interval corresponds to a maximum time interval associated with the plurality of token buckets.

12. A system for facilitating data transmission in a switch, comprising: processor; A non-transitory computer-readable storage medium storing instructions that, when executed by the processor, cause the processor to perform a method for facilitating data transfer, the method comprising: Obtain one or more configuration parameter sets for a plurality of traffic policing filters of the switch, wherein the traffic policing filters correspond to token buckets, and wherein the number of tokens in the token buckets indicates whether to forward packets associated with the traffic policing filters; determining a token allocation frequency for the plurality of traffic policing filters based on the one or more sets of configuration parameters; selecting a sampling interval from among the token allocation frequencies based on a selection policy; and An execution rate for the plurality of traffic policing filters is determined based on the sampling interval. 13 . The system of claim 12 , wherein a configuration parameter set in the one or more configuration parameter sets comprises an information rate and a burst size of a token bucket.

14. The system of claim 12, wherein the execution rate comprises a compliance rate for the plurality of traffic supervision filters, and wherein determining the compliance rate further comprises: Acquire a plurality of service data points from forwarding hardware of the switch; as well as The compliance rate is calculated based on the difference between the plurality of business data points and the sampling interval.

15. The system of claim 14, wherein the method further comprises: issuing a query to the forwarding hardware; as well as A business data point is obtained in response to the query.

16. The system of claim 14, wherein the method further comprises: A request for the compliance rate is obtained, wherein a first traffic data point is obtained at a time of the request, and wherein a second traffic data point is obtained at the sampling interval.

17. The system of claim 14, wherein the corresponding traffic data point is a cumulative data unit count of interfaces associated with the plurality of traffic policing filters.

18. The system of claim 12, wherein the switch is configured with a plurality of classifier policies, and wherein the sampling interval is associated with a first classifier policy; and The method further comprises: The second sampling interval is selected from token allocation frequencies of one or more traffic policing filters of the second classifier policy.

19. The system of claim 12, wherein the method further comprises: In response to determining that the sampling interval is less than a low watermark, marking the low watermark as the sampling interval; as well as In response to determining that the sampling interval is greater than a high watermark, marking the high watermark as the sampling interval.

20. The system of claim 12, wherein the selection strategy comprises selection based on one or more of: a maximum token allocation frequency, a minimum token allocation frequency, a mean of the token allocation frequencies, a median of the token allocation frequencies, and a weighted average of the token allocation frequencies.

21. The system of claim 12, wherein the plurality of traffic supervision filters comprises a hierarchical serial traffic policy filter associated with a plurality of token buckets, and wherein a representative time interval of the hierarchical serial traffic policy filter used to determine the sampling interval corresponds to a sum of time intervals associated with the plurality of token buckets.

22. The system of claim 12, wherein the plurality of traffic supervision filters comprises a hierarchical parallel traffic policy filter associated with a plurality of token buckets, and wherein a representative time interval of the hierarchical serial traffic policy filter used to determine the sampling interval corresponds to a maximum time interval associated with the plurality of token buckets.

Images