KR101039695B1 - Method for network bandwidth resource allocation and computing device using the same - Google Patents

Abstract

In the present invention, the token supply method for the bucket is determined based on the token status of the bucket at the time of providing the token to support the minimum bandwidth and the maximum bandwidth of the network bandwidth. By applying this token supply method, it is possible to prevent bandwidth waste that does not utilize the available bandwidth and effectively divide network bandwidth according to user's needs without complicated calculations.

Description

METHOOD FOR NETWORK BANDWIDTH RESOURCE ALLOCATION AND COMPUTING DEVICE USING THE SAME}

An object of the present invention is to provide a method for variously allocating network bandwidth resources to a service or a virtualized network adapter according to a user's intention, and to efficiently distribute the network bandwidth resources to each service without wasting network bandwidth resources. This ensures network quality of service.

The present invention is derived from research conducted as part of the IT growth engine core technology development project of the Ministry of Knowledge Economy and the Ministry of Information and Communication Research. [Task Management Number: 2008-F-026-01, Title: Development of Linux Kernel Technology for Upgrading Open SW Platform]

In general, the network management technology field can be divided into a traffic control technology field for preventing performance degradation in the case of overlapping network traffic and a resource allocation technology for allocating network bandwidth to each service according to an administrator's intention.

Traffic control technology is a commonly used technology in a wide range of communication fields. When the traffic control technology is used in the wired network environment field, it is used in the gateway or router field. Gateways and routers are devices that control where multiple physical networks are connected. The performance of a network can depend on traffic control technology.

In the field of network resource allocation technology, a token bucket technique using tokens is widely used.

The token bucket technique allocates token buckets to subjects who want to limit network bandwidth and supplies a certain amount of tokens to each token bucket. Here, the token corresponds to a kind of certificate in which a specific node is dedicated to the channel.

Packets processed in the token bucket technique can maintain a constant network processing speed by processing irregularly incoming processing requests at a constant rate per unit time to process only input data of tokens filled in the token bucket.

1 is a conceptual diagram illustrating a token bucket technique.

In FIG. 1, the token bucket is shown in a bowl shape and the token is shown in a drop shape to help understand the token bucket technique.

Referring to FIG. 1, the token bucket 101 charges the token 102. Typically, the concept of a 'token bucket' is used as a model for defining the characteristics of traffic. The token bucket 101 has two main parameters, 'token occurrence rate' and 'token bucket size'. The token generation rate defines the average data transfer rate over a relatively long time. The size of the token bucket 101 defines the transfer rate of data that may exceed the token generation rate for a short time. Tokens 102 exceeding the size of the token bucket 101 are discarded without being contained in the token bucket 101.

Token 102 is filled in the token bucket 101 by a user specified amount (per unit time).

The buffer 103 buffers the input data (or input packet) for each traffic class for each traffic class and inputs them to the comparator 104 according to the token 102 generated at a predetermined token generation rate. The comparator 104 determines whether the input packet buffered in the buffer 104 is processed.

Comparator 104 compares the amount of input data buffered by buffer 103 with the amount of tokens 102, and if the amount of tokens 102 present in token bucket 101 is greater than the amount of input data, The input data buffered by the buffer 103 is processed. When the input data is processed in the buffer 104, the token bucket 101 consumes the token 102 by the amount of input data processed in the buffer 104.

This token bucket technique is that if a particular service is allocated a network bandwidth and the particular service does not use the allocated network bandwidth, no other service can use the network bandwidth that the particular service does not use. For example, if service A and service B are each allocated 10 Mbps of bandwidth, even if service A uses only 5 Mbps, service B cannot use 5 Mbps of unused free space among the 10 Mbps allocated by service A, Only 10Mbps will be used. As such, the token bucket technique results in a waste of network bandwidth.

The token bucket technique as described above is a useful technique used in the field of network resource allocation technology so that a specific service does not exceed a specified network speed, but other services utilize an available network bandwidth that the specific service does not use. Does not support work-conserving mode.

In addition, the token bucket technique as described above may not set the amount of network bandwidth that can be maximized in the operation guarantee mode.

Accordingly, an object of the present invention is to provide a hierarchical network resource sharing method that supports a work-conserving mode and variously allocates network bandwidth resources according to user intention.

Network resource sharing method according to an aspect of the present invention for achieving the above object, in order to support the minimum bandwidth and the maximum bandwidth of the network bandwidth for each service in the network scheduler, the token bucket from the upper bucket and the upper bucket Configuring the tokens into a plurality of sub-buckets, receiving a minimum number of tokens corresponding to the minimum bandwidth that each sub-bucket can accommodate and a maximum corresponding to the maximum bandwidth that each sub-bucket can accommodate Setting a number of tokens, and supplying tokens from the upper bucket to each lower bucket based on the set minimum token number and the maximum token number.

According to another aspect of the present invention, a computing device includes an upper bucket, a plurality of lower buckets each having a minimum number of tokens and a maximum number of tokens set, and the upper buckets and the plurality of lower buckets are hierarchically configured. A token bucket for supplying tokens to the plurality of lower buckets according to a minimum token number and a maximum token number and a minimum bandwidth and the maximum token number corresponding to the minimum token number according to the tokens supplied to the lower buckets It includes a network scheduler that supports the maximum bandwidth corresponding to each service.

According to the present invention, network bandwidth resources are variously allocated for a service (or a virtualized network adapter) according to a user's intention. As a result, network quality of service (QoS) can be guaranteed by efficiently distributing network resources for each service without wasting network bandwidth resources.

In the present invention, a method for statically or dynamically setting a network bandwidth for each service is proposed based on a token bucket technique which is generally used to limit static network bandwidth.

Specifically, in the present invention, in the case of a statically designated network bandwidth, the corresponding network bandwidth is guaranteed by distributing the corresponding token to the designated network bandwidth every predetermined time.

On the other hand, for a network bandwidth that is not statically specified, the minimum guaranteed bandwidth (hereinafter, referred to as the minimum bandwidth) and the maximum used bandwidth (hereinafter, referred to as the maximum bandwidth) can be designated and implemented through the new token distribution policy proposed by the present invention. . In the present invention, in order to provide the minimum bandwidth and the maximum bandwidth of the network bandwidth, it is determined whether or not the corresponding token bucket needs more tokens than the minimum bandwidth based on the status of tokens present in the token bucket at the time of token distribution. .

According to the token distribution policy proposed by the present invention, any other service utilizes an idle network bandwidth that is not used by any service, thereby preventing waste of network bandwidth and effectively adjusting network bandwidth according to a user's request without complicated calculation. You can give a variety.

On the other hand, the term 'service' described throughout this specification means a scheduling target of a network scheduler that requires network bandwidth. In a virtualized environment in which several virtual machines are run on a single piece of hardware, the term 'service' may be referred to as a 'virtual network adapter' located on the virtual machine.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

2 is a conceptual diagram illustrating a hierarchical token bucket structure applied to a network resource sharing method according to an exemplary embodiment of the present invention.

2, in the network resource sharing method according to an embodiment of the present invention, a hierarchical resource management structure and a hierarchical token bucket structure for supporting a selective work-conserving mode are applied.

The hierarchical token bucket structure includes a root bucket, a branch bucket and a leaf bucket.

The root bucket 201 receives tokens corresponding to the total network bandwidth at regular intervals (or at regular time intervals), and distributes the supplied tokens to lower buckets located below them. The lower bucket of the root bucket 201 includes a branch bucket 202 and a leaf bucket 203.

The branch bucket 202 is a bucket that does not have an actual service connected to it and serves as an aisle. That is, the branch bucket 202 does not actually use the token to process the data, but merely distributes the token to a lower bucket located under the 202 itself.

A leaf bucket is actually a bucket that a service is connected to and uses its token provided from the root bucket 201 to process data, and does not have a lower bucket to distribute its token. Accordingly, three leaf buckets 203, 204, and 205 are shown in FIG. 2. Hereinafter, the three leaf buckets 203, 204, and 205 are referred to as a first leaf bucket 203, a second leaf bucket 204, and a third leaf bucket 205, respectively.

As such, the user may allocate a desired network resource by configuring a network resource management policy to be configured in a hierarchical network bucket structure as shown in FIG. 2.

Hereinafter, an operation process of the hierarchical token bucket structure shown in FIG. 2 will be described.

Tokens are supplied to the root bucket 201 at designated time intervals. At this time, the token is supplied to the root bucket 201 in an amount equal to the maximum speed (bandwidth) of the entire network.

The token supplied to the root bucket 201 is equally divided between the branch bucket 202 and the first leaf bucket 203 which are its sub-buckets. If the equally divided token exceeds the bucket size of the bucket 202 or 203, the token supply from the root bucket 201 to the bucket 202 or 203 is stopped.

If only the first leaf bucket 203 has a token left in use before, the token supplied to the first leaf bucket 203 will overflow before the branch bucket 202. In this case, when the token supplied to the first leaf bucket 203 overflows, the root bucket 201 stops supplying the token to the first leaf bucket 203 and supplies the token only to the branch bucket 202. do.

If the token overflows in the branch bucket 202, the token supplied from the root bucket 201 is discarded since there are no more buckets 202 and 203 to be delivered.

Thereafter, the tokens charged in the first leaf bucket 203 are used to process the data, and the tokens charged in the branch bucket 202 are the second leaf bucket 204 and the third leaf bucket which are sub-buckets of the own 202. 205 is supplied. In this case, the branch bucket 202 distributes the tokens evenly among the lower buckets of the self 202 until the token overflows.

Using the token supplied in this way, each of the first and second leaf buckets 204 and 205 transmits data to a target based on the token bucket technique described with reference to FIG. 1.

Meanwhile, the size of the bucket is determined by the maximum bandwidth to be supported. In other words, if a service wants to support a bandwidth of at least 5 Mbps and a maximum of 10 Mbps, then the bucket size will be 10 Mbps. It is not mentioned here that the size of the bucket is 10 Mbit because the size of the bucket depends on the unit time the bucket is charged. For example, if the unit time for refilling the bucket is 0.5 seconds, the bucket in the above example has a size of 5 Mbit, and if the unit time is 0.1 second, the bucket has a size of 1 Mbit.

In this way, if the service supports work-conserving mode, the bucket size can be regarded as infinite size. Of course, the charging token will not exceed the size of the root bucket at the top.

In a typical bucket, if the size of the bucket is infinite, the tokens may be infinitely accumulated if the token is not used to transmit data. However, the technique proposed in the present invention does not occur such a phenomenon, there is no problem caused by the infinitely large bucket size.

Token supply is sequentially performed from the root bucket 201 at the top. Since the token supply method of the present invention can be equally applied to all layers, only a method of supplying tokens from one upper bucket to a plurality of lower buckets can understand the token supply method of all the other layers.

As described above, the upper bucket supplies the token to the lower bucket according to the size of the lower bucket and the amount of tokens remaining in the lower bucket.

When a parent bucket supplies tokens according to the amount of tokens remaining in the child bucket (or the number of tokens), there are two cases in which there are no tokens remaining in the bucket and there are tokens remaining in the bucket. .

First, if there is no token remaining in the bucket, it will be determined that the bucket is overflowing, and if there is a spare token in the future, it will be divided. If there is a limit on the size of the bucket, it will be limited to the size of this bucket when giving extra tokens. That is, if the size of the bucket is equal to the minimum bandwidth guaranteed for the service, the bucket is not supplied even if there is a spare token, and as a result, only the minimum bandwidth is guaranteed. This means that this service does not support work-conserving mode.

On the other hand, there may be cases where the size of the bucket is larger than the minimum bandwidth or there is no limit on the size. In this case, if the size of the bucket is limited to not infinite, this size will mean the maximum bandwidth that the service can receive, and the service can only receive tokens with the maximum bandwidth size. Of course, if the size of the bucket is not limited, you can receive all of the extra tokens.

There are two main cases of remaining tokens in the bucket.

First, the token remaining in the bucket is equal to or greater than the minimum bandwidth. In this case, if the token remains above the minimum guaranteed bandwidth, the traffic of the service does not generate much, so the bandwidth corresponding to the amount of token remaining is sufficient and the token is skipped without additional supply. . These skipped buckets are excluded from the supply of spare tokens even if there is free space in the bucket.

The following is a case where the remaining tokens in the bucket are shorter than the tokens with the minimum bandwidth. In this case, it is determined that there is traffic of the corresponding service but the minimum bandwidth is sufficient, and only the token is charged as much as the minimum bandwidth is filled.

The parent bucket first distributes its tokens to each child bucket in the order described above. Then some buckets will be charged with tokens, and some buckets will not be charged with tokens. After this one-time charging process, there will be no tokens left.

If there are no remaining tokens, the token supply at that level is terminated, and the child buckets that receive the tokens supply tokens in the same way back to their own token buckets.

If there are remaining tokens, the parent bucket will be equally divided among the token buckets, which are the conditions for receiving free tokens. In this case, if a token is filled with a limited size bucket, the bucket no longer receives the token, and the token is supplied only to the remaining buckets. If this process is performed in order from the root bucket 201 at the top to the lower bucket, tokens will not be left in the branch bucket 202, and tokens will be accumulated only in the leaf bucket.

As a result of the above steps, if any of the leaf buckets support work-conserving mode, the tokens accumulated in the leaf buckets 203, 204, and 205 are the maximum bandwidth tokens supplied by the root bucket 201. More cases are likely to occur. Because the token supplied every time is the total bandwidth, and each leaf bucket will have a remaining token, so the sum of the sizes of all the leaf buckets 203, 204, and 205 is not equal to the amount of tokens supplied by the root bucket 201. Otherwise, the sum of all tokens in all buckets will be greater than the amount of tokens supplied to the root bucket every time. This can cause errors for the bandwidth specified for each service.

However, even if there is still available bandwidth, it is possible to prevent a case where the token is not used due to a misprediction due to a misprediction, and a token that does not use all of the previously supplied tokens on every charge will not be given more than the minimum bandwidth. Therefore, even if the size of the bucket is infinite, the amount of tokens that can be stored in the bucket is limited, so there is no possibility of temporary bandwidth congestion due to the excessive amount of tokens accumulated in the bucket. Therefore, in controlling the overall bandwidth, there is an advantage that can increase the accuracy.

3 to 6 are diagrams for explaining a token supply method supplied to a plurality of lower buckets from an upper bucket according to an embodiment of the present invention, Figure 3 is a lower bucket of each of the lower buckets according to an embodiment of the present invention 4 is a diagram illustrating a setting environment virtually set to receive tokens from the drawings, and FIGS. 4 to 6 are views illustrating embodiments of the token distribution process proposed by the present invention according to the setting environment illustrated in FIG. 3.

In order to explain the token supply method according to an embodiment of the present invention, each lower bucket will be described on the assumption that it is set as shown in FIG. 3.

Referring to FIG. 3, first, the upper bucket 301 is set to receive 50 tokens every predetermined time unit.

Assume that there are three lower buckets 302, 303, 304 below the upper bucket 301, and the three lower buckets 302, 303, 304 are bucket A 302, bucket B 303. And bucket C 304.

Bucket A 302 is set to be able to receive a minimum of 20 (min20), a maximum of 30 (max30) tokens from the upper bucket. Bucket B 303 can receive at least 15 tokens (min15) from the parent bucket 301, the maximum number of tokens that bucket B 303 can be supplied from the parent bucket 310 is unlimited. Is set to. Bucket C 304 is set to the same number of the maximum number of tokens that can be supplied from the upper bucket and the minimum number of tokens, each 15 pieces, in this case, bucket C 304 is an extra token even if the remaining tokens remain It means no supply.

Hereinafter, referring to FIGS. 4 to 6, a token supply scheme proposed by the present invention will be described according to a setting environment set in each lower bucket shown in FIG. 3.

FIG. 4 is a token in the case where there are no remaining tokens in the setting environment of the lower buckets shown in FIG. 3, when all of the lower buckets 302, 303, and 304 use all previously charged tokens. It is a figure for demonstrating a supply system.

As shown in FIG. 4, when there are no tokens remaining in all the lower buckets 302, 303, and 304, each of the lower buckets 302, 303, and 304 has a higher bucket ( The token is supplied from 301 (S402). Since there is no remaining token in the parent bucket, the token distribution in one cycle ends.

FIG. 5 is a diagram for describing a token supply method in a case where 10 tokens remain only in bucket C in a setting environment of lower buckets illustrated in FIG. 3.

Referring to FIG. 5, when 10 tokens remain only in the bucket C 304 (S501), the state of the bucket A 302 and the bucket B 303 are both short of tokens.

Thereafter, the upper bucket 301 distributes the token to each lower bucket according to the minimum number of tokens preset in each lower bucket (S502). That is, 20 tokens are distributed to bucket A 302 and 15 tokens are distributed to bucket B 303. At this time, since 10 tokens remain in the bucket C 304, only 5 tokens are distributed. Therefore, 10 tokens remain in the upper bucket 301 (S502).

After that, since 10 tokens remain in the upper bucket 301 (S502), the 10 tokens remaining in the upper bucket 301 are divided into five bucket A (302) and bucket B (302) (S503). ). Thus, bucket A 302 will have 25 tokens, bucket B 303 will have 20 tokens, and bucket C 304 will have 15 tokens.

The total number of tokens that each bucket 302, 303, 304 finally has is 60. These 60 tokens are more than 50 supplied by the parent bucket 301. The advantages and disadvantages of this are mentioned above.

As such, FIG. 5 shows a case where two or more buckets are supplied with an extra token.

FIG. 6 is a diagram illustrating a token supply method in a case where there are no tokens remaining in bucket A and bucket C and only 20 tokens remain in bucket B in the setting environment of the lower buckets shown in FIG. .

Referring to FIG. 6, since bucket A 302 and bucket C 304 lack tokens (S601), bucket A 302 and bucket C 304 each have an upper bucket ( The token is preferentially supplied from 301 (S602). At this time, since there are 20 tokens larger than 15, which is the minimum number of tokens, the bucket B 303 is excluded from the supply of tokens and the tokens are supplied only to the bucket A 302 and the bucket C 304. . As such, when the first token supply process S602 is completed, 15 tokens remain in the upper bucket 301.

In the bucket B 303, since 20 remaining tokens processed in the previous process remain, that is, the number of initial tokens is not '0', it is excluded from the additional token supply target.

In the first token supply process (S602), the upper bucket 301 supplies tokens to the buckets 302 and 304, and the remaining tokens may be divided into bucket A 302 and bucket C 304. (S603). At this time, since the size of the bucket C 304 is set to accommodate only 15 tokens, all remaining tokens are delivered to the bucket A 302. However, even in this case, since the size of the bucket A 302 is set to accommodate up to 30 tokens, the bucket A 302 does not receive all 15 tokens remaining in the upper bucket 301 and only supplies 10 tokens. Receive. Accordingly, bucket A 302 will only hold 30 tokens, which is a preset maximum.

Thereafter, in FIG. 6, the bucket A, bucket B, and bucket C do not have another lower bucket capable of receiving tokens at the bottom, and the upper bucket 301 discards the remaining five tokens.

It will be easy to understand the token supply method of the present invention through the process described in the embodiments of Figures 4, 5 and 6 above.

The present invention can assign and support a minimum bandwidth and a maximum bandwidth to each service by using a network scheduling scheme based on the token supply scheme described so far.

The network resource sharing method of the present invention may be implemented as a program and stored in a recording medium (CD-ROM, RAM, ROM, floppy disk, hard disk, magneto-optical disk, etc.) in a computer-readable form. This process can be easily carried out by those of ordinary skill in the art to which the detailed description thereof will be omitted.

The present invention can be applied to network bandwidth resource management of a service consisting of a single network connection or multiple network connections to guarantee the quality of service (QoS) of network services in a general computing environment or a network environment.

In addition, the present invention can be applied to network bandwidth resource management of a virtual network adapter located in a plurality of virtualization servers in a virtualization environment, and can be applied to routers, gateways, switches, and the like that control network traffic.

Although the present invention has been described with reference to the embodiments illustrated in the drawings, this is merely exemplary, and it will be understood by those skilled in the art that various modifications and equivalent other embodiments are possible. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

1 is a conceptual diagram illustrating a token bucket technique.

2 is a conceptual diagram illustrating a hierarchical token bucket structure applied to a network resource sharing method according to an exemplary embodiment of the present invention.

3 is a diagram illustrating a setting environment virtually set in each lower bucket to receive a token from an upper bucket according to an embodiment of the present invention.

4 to 6 are diagrams for showing embodiments of the token distribution process proposed by the present invention according to the setting environment shown in FIG.

Claims (10)

Configuring a hierarchical token bucket including a higher bucket and a plurality of lower buckets receiving tokens from the upper bucket to support a minimum bandwidth and a maximum bandwidth for each corresponding service in a network scheduler; Setting the minimum number of tokens of the minimum bandwidth and the maximum number of tokens of the maximum bandwidth that each of the lower buckets can accommodate; And Supplying tokens from the upper bucket to the lower bucket according to the set minimum token number and the maximum token number, In the step of supplying the token, The criteria for supplying tokens are determined according to the amount of tokens remaining in the sub-bucket at the time of token supply and the size of the sub-bucket. delete The method of claim 1, wherein in the step of supplying the token, At the time of supplying the tokens, if there are no tokens remaining in the corresponding sub-buckets, the tokens more than the minimum number of tokens are supplied to the corresponding sub-buckets, And the network scheduler determines that a corresponding service corresponding to the corresponding lower bucket requires a token equal to or greater than the minimum bandwidth. The method of claim 1, wherein in the step of supplying the token, At the time of supplying the token, when there is a token remaining in the lower bucket, the network scheduler determines that the service corresponding to the lower bucket does not require the number of tokens equal to or greater than the minimum bandwidth. How to share network resources. The method of claim 1, wherein the supplying a token to the corresponding lower bucket comprises: And when the minimum number of tokens and the maximum number of tokens set in the corresponding lower bucket are the same, only the minimum number of tokens is supplied to the corresponding lower bucket. The network scheduler of claim 1, wherein when the maximum number of tokens set in the lower bucket among the lower buckets is the same as the minimum token number, the network scheduler includes: And determining that the service corresponding to the corresponding lower bucket does not require an available network bandwidth. The method of claim 1, wherein the setting of the maximum number of tokens corresponding to the maximum bandwidth comprises: If the maximum bandwidth supported by the service is not limited, the network resource sharing method, characterized in that the maximum number of tokens of the lower bucket corresponding to the service is set to infinite. The method of claim 7, wherein in the step of supplying the token, And the number of tokens supplied by the corresponding lower bucket having the maximum number of tokens set to infinity may not exceed the number of tokens supplied by the upper bucket. The method of claim 1, wherein supplying the token comprises: The upper bucket preferentially supplying each of the lower buckets a token having a minimum number of tokens set in the lower buckets; After supplying the minimum number of tokens to each of the lower buckets preferentially, if there are remaining tokens in the upper bucket, remaining tokens in the upper bucket are not exceeded until the maximum number of tokens set in each lower bucket is not exceeded. Redistributing to each of the lower buckets; And After distributing the token to each of the lower buckets, if the remaining tokens in the upper bucket still exist, distributing the remaining tokens to each of the lower buckets instead of consuming them. Network resource sharing method comprising a. An upper bucket, a plurality of lower buckets each having a minimum number of tokens and a maximum number of tokens set, and the upper buckets and the plurality of lower buckets are hierarchically configured to provide the upper buckets according to the minimum number of tokens and the maximum number of tokens. A token bucket, the bucket supplying tokens to the plurality of sub-buckets; And A network scheduler that supports a minimum bandwidth corresponding to the minimum number of tokens and a maximum bandwidth corresponding to the maximum number of tokens for each service according to a token supplied to the lower bucket, The criteria for supplying the token to the plurality of lower buckets by the upper bucket is Computing device, characterized in that determined by the amount of tokens remaining in the sub-bucket at the time of token supply and the size of the sub-bucket.

Images