WO2012116540A1

WO2012116540A1 - Traffic management method and management device

Info

Publication number: WO2012116540A1
Application number: PCT/CN2011/079173
Authority: WO
Inventors: 卢胜文
Original assignee: 华为技术有限公司
Priority date: 2011-02-28
Filing date: 2011-08-31
Publication date: 2012-09-07
Also published as: CN102118314A

Abstract

Provided in embodiments of the present invention are a traffic management method and a management device. The method comprises: receiving notifications transmitted by at least two single boards requesting for a token, the number of tokens corresponds to the number of packets requiring transmission in a to-be-scheduled-packet queue of the single board; on the basis of the number of tokens requested, distributing tokens to the to-be-scheduled-packet queue, thus allowing the single board to transmit, on the basis of the token distributed, the packets in the to-be-scheduled-packet queue. The management device comprises a receiving module and a distributing module. In the method and management device provided in embodiments of the present invention, by using the management device for centralizing traffic management, collective and centralized scheduling is allowed for previously independently managed traffic of the single boards, thereby allowing collective and effective management of data streams having possible association with each other and distributed on different single boards, and satisfying the needs of traffic management.

Description

Method and management device for traffic management

The present invention relates to the field of communications, and more particularly to a method and a management apparatus for traffic management in the field of communications. Background technique

With the rise of the Internet, various services began to be carried on the Internet Protocol (IP) network. At the same time, IP networks penetrated into the traditional telecommunications field, and data services gradually replaced traditional voice services, and gradually became the main body of communication services. To ensure that various telecommunication services can meet the user's business requirements, traffic management needs to be performed on network devices (Traffic Management,

ΤΜ ), to ensure that the traffic of various services can be controlled.

In order to meet the traffic management requirements of complex services, multi-level traffic management is usually performed on each service board, but the managed traffic is limited to the traffic in the service board. A service board is a board in a network device. Each board can perform various types of service processing, such as data stream access, forwarding, multiplexing, routing, labeling, flow control, traffic shaping, and so on. Multi-level traffic management enables the traffic to pass through the board in a single-level management manner, which meets the requirements of the total output of the board.

With the development of technology, in order to improve the processing power and the number of interfaces of the system, distributed processing technology is adopted in network devices such as switches, routers, and gateway devices of wireless data services, that is, the service processing is distributed more. The processing is performed on the boards (that is, the service boards) to improve the overall processing capability of the network devices. Traffic is distributed to different boards, and traffic management is distributed to different boards. Distributed traffic management is formed.

In the prior art, traffic management can only be performed independently within each board. For example, in order to control the ingress traffic of a card, you can perform traffic management on the data stream input from the inbound interface of the card, discard excessive packets, prevent impact on the device, affect device performance, and perform traffic management on the ingress traffic. After that, the business process of the business board is performed. In order to control the egress traffic of the service board, traffic management is performed after the service processing of the service board. In this case, the data stream after the service processing needs to be cached before traffic management can be performed, so a large amount of storage space is consumed.

However, as traffic is distributed to different boards for processing, traffic management independently within each board cannot meet the needs of traffic management. For example, when traffic of the same service enters a network device from different inbound interfaces and enters different boards, or when the same service When the traffic is distributed to the boards that are output from different outbound interfaces, the traffic that is originally associated with traffic management is no longer able to manage traffic. The management of the boards can be performed separately. The traffic of the service output from the network device does not meet predetermined requirements such as bandwidth and delay requirements, which affects the effectiveness of traffic management. Summary of the invention

The embodiment of the invention provides a method and a management device for the traffic management, which can solve the problem that the data traffic distributed to multiple boards cannot be uniformly managed, so that the data streams distributed to different boards can be effectively managed to meet the requirements of traffic management.

On the one hand, the embodiment of the present invention provides a method for traffic management, including: receiving a notification of a request token sent by at least two boards, the number of tokens requested by each board, and the to-be-scheduled message in the board. The number of packets to be transmitted in the queue corresponds to each other; according to the number of requested tokens, the packets to be scheduled are transmitted.

On the other hand, an embodiment of the present invention provides a management apparatus for traffic management, including: a receiving module, configured to receive a notification of a request token sent by at least two boards, and the number of tokens requested by each board is An allocation module is configured to allocate a token to the to-be-scheduled message queue according to the number of requested tokens, so that the card root is according to the present invention. In the technical solution provided by the embodiment, the management device allocates the token according to the notification of the plurality of board request tokens, so as to control the packet transmission of the board through the allocation of the token, so that the traffic in the board that is originally independent of the traffic management is performed. Unified, centralized scheduling can be achieved, unlike the prior art, the traffic in each board is managed separately, independently, and isolated. Therefore, the centralized traffic management performed by the management device can uniformly and effectively manage data streams that may be associated with each other on different boards, thereby satisfying the requirements of traffic management. DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention. Those skilled in the art can obtain other drawings according to these drawings without paying any creative work. 1 is a flow chart showing a method of traffic management according to an embodiment of the present invention;

2 is a flow chart showing another method of traffic management according to an embodiment of the present invention; FIG. 3 is a schematic diagram showing an example of traffic management according to an embodiment of the present invention;

4 is a schematic diagram of a board using a method of traffic management according to an embodiment of the present invention; FIG. 5 is a schematic diagram showing another example of traffic management according to an embodiment of the present invention; A block diagram of a management apparatus for traffic management according to an embodiment of the present invention; FIG. 7 is a block diagram showing the structure of another management apparatus for traffic management according to an embodiment of the present invention. detailed description

BRIEF DESCRIPTION OF THE DRAWINGS The technical solutions of the embodiments of the present invention will be clearly and completely described in the following description of the embodiments of the present invention. It is obvious that the described embodiments are a part of the embodiments of the present invention, and not all embodiments. All other embodiments obtained by a person skilled in the art based on the described embodiments of the present invention without creative work shall fall within the protection scope of the present invention.

First, a method 100 of traffic management in accordance with an embodiment of the present invention will be described in conjunction with FIG.

As shown in FIG. 1, the method 100 includes: in S110, receiving a notification of a request token sent by at least two boards, and the number of tokens requested by each board and the queue to be scheduled in the board need to be transmitted. In S120, the token is allocated to the to-be-scheduled message queue according to the number of the requested tokens, so that the board transmits the packet in the message queue to be scheduled according to the allocated token.

A management device that performs centralized traffic management on at least two boards receives notifications from the boards. The card requests a token from the management device by using the notification. The number of the requested tokens can correspond to the number of packets to be transmitted in the queue to be scheduled in the card. The management device allocates a token to the queue to be scheduled in the board according to the number of tokens requested by the board. After receiving the token, the board transmits the packet in the queue to be scheduled according to the token assigned by the management device.

According to the method for traffic management provided by the embodiment of the present invention, the management device allocates a token according to the notification of the plurality of board request tokens, so as to control the transmission of the packet by using the token allocation, so that the traffic management is originally performed independently. The traffic in the board can be uniformly and centralizedly scheduled. Unlike the prior art, the traffic in each board is managed separately, independently, and isolated. Therefore, by using centralized traffic management, data flows that may be associated with each other on different boards can be managed uniformly and efficiently, thereby meeting the requirements of traffic management. Hereinafter, S110 and S120 according to an embodiment of the present invention will be specifically described.

In S110, the notification of the request token sent by the at least two boards is received, and the number of tokens requested by each board corresponds to the number of packets to be transmitted in the queue of the to-be-scheduled message in the board.

The management device manages at least two boards and performs centralized unified scheduling of traffic in at least two boards.

On each board, there can be only one queue to be scheduled, or multiple queues to be scheduled. The board can cache the packets to be transmitted in different queues to be scheduled according to a predetermined policy, for example, based on the packet type, the user who sent the packet, the destination address of the packet, and the output port of the packet. The packet to be transmitted may be a packet received from another board or a packet generated by the board itself. For example, the board can cache the packet according to the type of the packet, and store the packet carrying the voice information in the queue of the message to be scheduled dedicated to the voice information, and store the message carrying the video information in the video dedicated to the video. The message queue to be scheduled is medium.

The number of the requested tokens can be represented by the number of packets to be transmitted, the number of bytes of the packets, the number of packets, or the increment of the number of bytes in the queue. Of course, those skilled in the art will also appreciate carrying other information in the notification to characterize the number of tokens requested. Since the number of tokens requested by the notification is determined based on the packets to be transmitted in the queue to be scheduled, the number of tokens requested can be considered to correspond to the number of packets to be transmitted.

For example, if the board has two queues to be scheduled, when the first queue to be scheduled needs to transmit three packets, and the second queue to be scheduled needs to transmit five packets, each report is assumed. The packet has 100 bytes, and the board carries the first to-be-scheduled message queue with 300 bytes to be transmitted in the notification, and the second to-be-scheduled message queue has 500 bytes of information to be transmitted, to the management device. Request a total of 800 tokens (assuming 1 token corresponds to 1 byte). The number of 800 tokens requested corresponds to the number of packets to be transmitted in the queue of scheduled packets in the card.

The board in the S110 can be the service board of the network device. Those skilled in the art may think that the board in the S110 may also be other devices that may process data in the network device and transmit data in the future, and the traffic needs to be uniformly scheduled and managed.

The notification received by the management device from the board may be a notification that the board sends independently. The notification may also be a notification that the management device itself determines based on the information carried by the traffic transmitted by the board. The notification determined by the management device itself can also be regarded as a notification that the management device receives from the board, because this still needs to be determined by means of information from the board. For example, the management device determines that there are a large number of video packets that need to be transmitted on the board according to the traffic transmitted by the board, and the maximum size that the board is allowed to send according to the board. Bandwidth allocates tokens to the board.

In S120, a token is allocated to the to-be-scheduled message queue according to the number of the requested tokens, so that the board transmits the packet in the message queue to be scheduled according to the allocated token.

The management device allocates a token according to the number of tokens requested by the board. For example, based on the above example, the management device may allocate 300 tokens to the first to-be-scheduled message queue of the board, and allocate 500 tokens to the second to-be-scheduled message queue of the board. The board transmits the packets in the queue to be scheduled according to the token allocated by the management device. For example, after the board acquisition management device allocates 300 tokens to the first to-be-scheduled message queue, the three packets in the first to-be-scheduled message queue are transmitted, and the acquisition management device allocates the second to-be-scheduled report. After the 500 tokens of the text queue, the five texts in the second queue of the scheduled message are transmitted.

The management device may assign a token to the queue of messages to be scheduled in the board based on a plurality of predetermined policies. The predetermined policy can be set in the management device in advance, or can be dynamically adjusted according to the statistics of the data traffic in each board. The traffic management policy known in the prior art may be used, or the traffic management policy may be adopted in the future, as long as it can send packets and send packets in different queues to be scheduled. Just wait for control.

According to an embodiment of the present invention, the management device may assign a token to the queue to be scheduled based on the priority scheduling policy or the load balancing policy.

In the priority scheduling policy, the management device schedules the packets according to the priority of the queues to be scheduled, so that the important packets are stored in the queue with the highest priority of the packets to be scheduled, and the packets are preferentially scheduled. For example, if a packet is cached according to the packet type, there is a voice to-be-scheduled message queue for storing voice packets, a video to-be-scheduled message queue for storing video packets, and data for storing data packets such as pictures, emails, and texts. Schedule message queues. The priorities of the voice to-be-scheduled message queue, the video to-be-scheduled message queue, and the data to-be-scheduled message queue are sequentially decreased. When a message indicating that the message to be scheduled in the queue is to be transmitted, the message is preferentially assigned to the voice to-be-scheduled message queue. If there are remaining tokens, the message waiting to be transmitted in the queue to be scheduled is further satisfied. The packet finally meets the packet to be transmitted in the data queue to be scheduled.

For example, it is assumed that, according to the user buffered message, there is a queue of A to be scheduled to store the message sent by the A user, a queue of the B to be scheduled to store the message sent by the B user, and a C to be sent by the C user to send the message. Schedule 4 essay queues. Due to reasons such as payment, the priority of the user is higher than the priority of the B user, and the priority of the B user is higher than the priority of the C user. First, the A user needs to be sent. When a message to be transmitted appears in the queue to be scheduled A, the priority is adjusted to A. The message queue is assigned a token, followed by the B queue to be scheduled, and then the C queue to be scheduled.

In the load balancing policy, the management device allocates a token to the to-be-scheduled message queue of the requesting token, so that the to-be-scheduled message queue can be uniformly scheduled, so that the traffic of each board can be uniformly balanced, and one board is avoided. The traffic in the middle is always in a waiting state and the phenomenon of transmission is not obtained.

For example, if a plurality of boards have packets to be transmitted, if the management device determines that there are packets in the boards to be transmitted at a certain token allocation time, the tokens can be evenly distributed to the boards. The traffic in the board can be treated equally.

For example, if the traffic of a particular board is larger than the traffic of other boards, the management device can allocate more tokens to the specific board when the traffic of other boards is balanced. More traffic can be transferred to avoid load buildup.

According to an embodiment of the present invention, the management device may periodically assign a token to the message queue to be scheduled. The number of tokens requested by the board may not be met by the management device at one time. For example, the management device can only allocate a fixed number of tokens to a to-be-scheduled message queue in the board at a time, or the total number of tokens that can be allocated by the management device each time is less than the total number of tokens requested. Or because the board has a lower priority and there are not enough tokens to be allocated, etc., the management device may not be able to satisfy the number of tokens requested by the board at one time. In this way, the management device needs to periodically assign a token to the queue to be scheduled, and flexibly allocate the token by sending the token multiple times to satisfy the predetermined scheduling policy. In addition, the time interval between periodically assigning tokens may be equal or unequal.

For example, the first to-be-scheduled message queue requires 300 tokens as an example. The management device may assign 300 tokens to the first to-be-scheduled message queue at a time, or may assign tokens to it multiple times periodically. For example, the token may be allocated in such a manner that 100 tokens are allocated each time, three times in total, or the available tokens may be allocated multiple times according to the current token usage until the demand of 300 tokens is satisfied. Of course, those skilled in the art can also easily think of determining how to assign a token based on a predetermined policy, and if the token requirement cannot be met at one time, the token requirement is satisfied by multiple allocations.

According to an embodiment of the present invention, the board may transmit the message in the message queue to be scheduled according to the allocated token based on the token bucket technology. The board can store the token received from the management device in the token bucket. According to different settings, each token in the token bucket can correspond to one byte, or multiple bytes, and can directly correspond to one packet. If there is a token in the token bucket, then Traffic is allowed to be sent, otherwise, traffic is not allowed to be sent. If the number of tokens in the token bucket satisfies the transmission of a complete packet, the packet is transmitted and the corresponding number of tokens are deleted. If the number of tokens in the token bucket is insufficient to satisfy a complete packet. If the message is transmitted, the message is not transmitted temporarily, and the message is transmitted until the new message is received and the complete message is satisfied. Messages in the text queue can only use those tokens for it. The tokens in the token bucket can also be the tokens shared by the queues to be scheduled. The tokens are used according to the rules for using the tokens in the queues to be scheduled. For example, the voice to-be-scheduled message queue in the board preferentially uses the token. If there are remaining tokens in the token bucket, it is used by the video to-be-scheduled message queue, and then used by the data to-be-scheduled message queue.

According to the method of the traffic management provided by the embodiment of the present invention, the management device allocates the token according to the notification of the plurality of board request tokens, so as to control the packet transmission of the board through the allocation of the token, so that the traffic management is originally performed independently. The traffic in the board can be uniformly and centralizedly scheduled. Unlike the prior art, the traffic in each board is managed separately, independently, and isolated. Therefore, by using centralized traffic management, it is possible to uniformly and effectively manage data flows that may be associated with each other on different boards, thereby meeting the needs of traffic management.

In Fig. 2, a flow diagram of another method 200 of traffic management in accordance with an embodiment of the present invention is shown.

Compared with the method 100 of FIG. 1, S210 and S220 in FIG. 2 are substantially the same as S110 and S120 in FIG. 1, and therefore will not be described again.

According to an embodiment of the present invention, the method 200 may further include, after S220, S230, when the number of allocated tokens is equal to the number of requested tokens, stopping the allocation of the queues to be scheduled to be scheduled for the board in the management device. Two counters are set for the queue to be scheduled. The first counter is used to record the number of tokens requested by the board for the queue of the message to be scheduled, and the other counter is used to record the number of tokens allocated by the management device to the queue of messages to be scheduled. When the count values of the two counters are equal, it indicates that the assigned token can satisfy the packet to be transmitted in the queue of the message to be scheduled, and therefore, the token is stopped.

It is also possible to set a counter for the to-be-scheduled queue of the board in the management device. The initial value of the counter is the number of tokens that the board requests for the queue of the message to be scheduled. After the management device allocates a token to the queue to be scheduled, the counter is subtracted from the assigned number of tokens, when the management device When the board receives a new notification for the queue to be scheduled, it adds the counter to the requested number of tokens. When the counter's count value is zero, the assignment token is stopped.

Of course, it is also possible to set two counters or one counter for the board in the management device. Similar to the above description, when the count values of the two counters of the board are equal, or the value of one of the counters of the board is zero, the tokens allocated to the board can satisfy all the to-be-scheduled messages in the board. If the queue needs to transmit a message, the token is stopped.

According to an embodiment of the present invention, the method 200 may further include S240 after S220. If the board determines that the number of assigned tokens is less than the requested number of tokens, the notification of the request token is sent again.

After the management device assigns a token to the queue to be scheduled in the board, the board needs to determine whether the token allocation is over. In the case that the management device receives the notification and performs the token allocation only once, if the board receives the token, it determines that the token allocation ends. If the board does not receive the token and waits for the token to expire, Determine the end of the token assignment. The management device may send the specific information to indicate the end of the token allocation when the management device receives the notification, and may periodically allocate the tokens multiple times. If the board receives the specific information, Then, it is determined that the token allocation ends. If the board does not receive the specific message and the time of waiting for the token expires, it is determined that the token allocation ends.

When the board determines that the token allocation is over, if the number of tokens that the management device allocates to the board cannot be full, the number of tokens that are requested cannot be transmitted, and the board requests the management device again. Token. The number of tokens that are requested at this time may be the number of tokens corresponding to the packet that has not been acquired by the previous one, or the number of tokens corresponding to the number of packets that need to be transmitted in the queue to be scheduled. The message that needs to be transmitted currently includes the packet that has not yet obtained the token, and also includes the newly buffered packet that needs to be transmitted.

In this way, the board sends a notification again by actively discovering that the number of assigned tokens cannot satisfy the requested number of tokens, and can timely request re-scheduling of the unscheduled packets, and can also reduce errors caused by the token allocation process. The packets scheduled to be scheduled are not scheduled in time, and thus have an impact on traffic management performance.

Although S240 is executed after S230 in Fig. 2, S240 may be executed before S230, and S230 and S240 may be simultaneously executed.

The traffic management method according to the embodiment of the present invention, when the traffic of the same service enters the network device from different inbound interfaces and enters different boards, or when the traffic of the same service is distributed differently When the outbound interface outputs different boards, centralized traffic management is performed by the management device, and unified traffic management can be performed on these originally associated data flows that are desired to be uniformly managed. However, unlike the prior art, only the individual policies can be used. The board is managed separately. Therefore, the requirements of traffic management can be met, and the effectiveness of traffic management can be improved. In addition, the traffic management can be performed on the board in the process of data processing (such as forwarding, labeling, etc.), and the packet buffer can be shared with the service processing of the board, and the packet is directly transmitted according to the token bucket technology. Therefore, it is no longer necessary to open up new storage space and then cache the message, thereby saving storage space and improving performance.

Next, an example of traffic management according to an embodiment of the present invention will be exemplified. 3 and 5 respectively show schematic diagrams of examples of traffic management according to an embodiment of the present invention.

In Figure 3, the management device 340 performs centralized traffic management of the traffic of the boards 310, 320, and 330. Each board can have multiple queues to be scheduled and cache the corresponding packets in the queue to be scheduled.

The management device 340 records the scheduling characteristics of each queue to be scheduled to be scheduled, and the characteristics may include at least one of the following: scheduling priority, queue scheduling mode, number of packets owned by the queue, and traffic shaping of the total egress traffic of the queue. parameter.

The management device 340 can manage the queues of the to-be-scheduled messages to be scheduled in the boards 310, 320, and 330 according to the set. These to-be-scheduled message queues can be divided into different sets by a predetermined policy. The voice to be scheduled packet queues of the buffered voice packets in the boards 310, 320, and 330 are divided into voice sets, and the video packets of the video packets are buffered in the boards 310, 320, and 330. The scheduling message queue is divided into a video set, and the data to-be-scheduled message queues of the data packets such as pictures, mails, and texts in the boards 310, 320, and 330 are divided into data sets, and the like. Between different sets, different sets may be scheduled according to a predetermined policy, for example, based on a priority scheduling policy or a load balancing policy, the voice to-be-scheduled message queues in the voice set are preferentially scheduled, or an equal order is assigned to each set. Cards are dispatched. In each set, different queue scheduling and traffic shaping strategies can also be implemented independently. For example, for the voice collection, different queues of the to-be-scheduled message can be set according to the user, and the packets in the queue of the to-be-scheduled message of the specific user are preferentially scheduled. For the video collection, different to-be-scheduled reports can be set according to the destination address. The text queue, and allocates a specific transmission bandwidth for the queue of messages to be scheduled for a specific destination address, and so on.

The packets are cached in the queues of the to-be-scheduled packets of the board. The real-time queue-to-queue or egress scheduling is performed by the board. The management device 340 manages and controls the packets to be scheduled. The scheduling of messages in the queue. Between the boards 310, 320, and 330 and the management device 340 Message links are connected, and messages are not transmitted by means of data packets. The message link can require small delay and high link reliability, which enables fast and efficient centralized management.

The board can be configured with the to-be-scheduled message queues to be managed by the management device 340, and the set of the to-be-scheduled message queues to be centrally managed by the management device 340 can be configured to facilitate the management device 340 according to the predetermined policy. Perform centralized scheduling.

Each board can periodically notify the management device 340 of the number of bytes of the message to be transmitted in the respective queues to be scheduled. The advertising unit can be advertised in bytes or in byte blocks (for example, 128 bytes is a byte block). Notifying the management device 340 of the number of bytes of text can be considered as requesting scheduling control from the management device 340. The number of advertised message bytes is mainly used by the management device 340 to determine whether the queue of the message to be scheduled is empty and whether the token needs to be allocated, regardless of the number of specific tokens allocated each time.

If all the packets in the queue to be scheduled are obtained, the board can be advertised. The board can advertise the number of packets to be transmitted in the queues of the packets to be scheduled at one time, or the number of packets to be transmitted in the queue of the packets to be scheduled. The board can adjust the frequency of sending notifications according to the ratio of the number of bytes of packets in the queue to be scheduled that do not acquire tokens to the total number of bytes. The higher the ratio, the faster the transmission.

After receiving the notification sent by the board, the management device 340 allocates the token based on the number of tokens requested. The management device 340 can control the number of messages to be transmitted by the board according to a predetermined policy by assigning tokens. The number of tokens allocated by the management device 340 may be determined by an egress flow parameter of the set to which the to-be-scheduled message queue belongs (for example, a committed burst size CBS, an excess burst size EBS, a committed information rate CIR, a peak information rate PIR, etc.). determine.

After the token received by the board receiving management device 340 to the queue to be scheduled, the traffic shaping can be performed based on the token. For example, the token bucket technology can be used to schedule a packet that acquires a token from a token bucket to a subordinate queue or an egress.

4 shows a schematic diagram of a single board 400 utilizing a method of traffic management in accordance with an embodiment of the present invention. The single board 400 may be any one of the boards 310, 320, and 330 of FIG.

The board 400 includes a queue management module 410, a to-be-scheduled message queue 420, a token bucket 430, and a lower-level queue or outlet 440.

The queue management module 410 can advertise the unscheduled message bytes to the management device to request the acquisition of a corresponding number of tokens and receive the token assigned by the management device. After receiving the token, the queue management module 410 also delivers the assigned token to the token bucket 430. When the token in the token bucket 430 is full, Discard the newly issued token. In addition, the queue management module 410 also manages the message queue 420 to be scheduled, in which the message to be transmitted is buffered. The packets buffered in the to-be-scheduled message queue 420 are sent to the lower-level queue or the egress 440 after the tokens in the token bucket 430 are acquired, and the corresponding number of tokens are deleted from the token bucket 430. The queue management module 410 controls the transmission of the packets in the to-be-scheduled message queue 420 based on the tokens in the token bucket 430, thereby completing traffic shaping in the board 400.

In the following, a method for traffic management according to an embodiment of the present invention is specifically described by taking each of the boards as having only one queue to be scheduled. In this example, centralized traffic management is performed to limit the export bandwidth. Those skilled in the art can easily imagine that the situation in which each board has multiple queues of messages to be scheduled is similar.

Referring to FIG. 3 again, it is assumed that the board 310 has a queue A to be scheduled, the board 320 has a queue B to be scheduled, and the board 330 has a queue to be scheduled (:. from A, B, and C) The packets output by the inbound interface are respectively cached in the queues of the to-be-scheduled packets (called "queues") A, B, and C of the three access boards of the access device (that is, the example of the board). The load balancing policy is scheduled in a polling manner.

Assume that 10 messages are input from access point A, and the total number of bytes is 8000, input from access point B.

20 packets, the total number of bytes is 15000, and 30 packets are input from the access point C, and the total number of bytes is 20000. The unit is allocated with 1000 bytes as the token, that is, one token is allocated corresponding to 1000 bytes.

The boards 310, 320, and 330 can advertise the number of message bytes waiting to be scheduled to the management device 340 in units of byte blocks. In this example, assuming that 1 byte block also has 1000 bytes, the boards 310, 320, and 330 respectively advertise to the management device 340 that the packets in the respective queues A, B, and C that do not acquire the token have 8 , 15 and 20 byte blocks. At this time, one byte block corresponds to one token allocation unit.

The management device 340 assigns a token to the eight queues of eight, B, and C at a rate of 5M total outlet bandwidth, and assumes that a total of 12 token blocks can be assigned a token within the time interval in which the token is allocated.

On the first poll, the management device 340 simulates three queues for polling scheduling, and assigns four tokens to each of the three queues A, B, and C. After obtaining four tokens, the three queues A, B, and C can respectively send 4000 bytes of packets.

On the second poll, the management device 340 still allocates four tokens to each of the three queues A, B, and C. After obtaining four tokens, the three queues A, B, and C respectively send 4,000-byte packets.

In the third round of polling, since the A queue has no packets to send, it is no longer assigned to the A queue. New token. At this point, there are 7 byte blocks in the B queue that need to be sent, and there are 12 byte blocks in the C queue that need to be sent. The management device 340 allocates six tokens to the C queue based on the load balancing policy. In this way, the B and C queues can respectively send 6,000-byte packets.

In the fourth polling, since the B queue has 1 byte block and the C queue has 6 byte blocks, it is only necessary to assign 1 token to the B queue and 6 tokens to the C queue. can.

In this way, after the management device 340 receives the notifications from the boards 310, 320, and 330, the traffic in each board can be centrally managed, and the tokens are allocated multiple times based on the load balancing policy to meet the requirements of the traffic management, and the A is guaranteed. The total bandwidth transmitted by the three queues, B, and C matches the scheduling bandwidth (ie, 5M) configured for the set to which the three queues belong.

FIG. 5 shows another example of traffic management in accordance with an embodiment of the present invention.

In the example shown in Figure 5, the notification sent by the board to the management device can carry the number of packets. Each time the management device receives a notification, the token is assigned to the board that sent the notification independently and periodically. The management device assigns a token to the board to carry the token allocation information by confirming the ACK message, and the ACK message can also respond to the receipt of the notification. If the board finds the loss of the ACK message (for example, timeout, error correction, etc.), it waits for the specific information indicating the end of the token allocation to be received, and then recalculates the report waiting to be transmitted in the queue of the to-be-scheduled message in the board. The number of texts, the notification of the request token is sent again.

As shown in FIG. 5, the management device 520 that performs centralized traffic management sequentially receives notifications of sequence numbers 1, 2, and 3 from the board 510, and the notifications carry "^ bytes increments of 2000, 500, and 500, respectively. 520 sends an ACK message in response to each sequence number to the board 510 multiple times according to the predetermined scheduling policy. Each ACK message carries token allocation information indicating that 500 tokens are allocated (1 token corresponds to 1 byte). However, due to a transmission error, in the ACK message 1 in response to the notification of the sequence number 1, one ACK message is lost, and the ACK message in response to the notification of the sequence number 2 is also lost. Then, the board 510 expires when the timer expires. The loss of the ACK message is found, and continues to wait for the management device 520 to assign the token. The ACK message 3 in response to the notification of sequence number 3 is correctly transmitted, and an ACK message 3 carrying the specific information indicating the end of the token allocation is transmitted. When receiving the ACK message with the specific information from the management device 520, the board 510 recalculates the number of bytes of the message waiting to be transmitted in the queue of the to-be-scheduled message of the board 510, and The number of bytes of the message is carried in the notification with sequence number 4 and sent to management device 520.

The method of traffic management according to an embodiment of the present invention has been described above, and a structural block diagram of a management apparatus for traffic management according to an embodiment of the present invention will be described below with reference to FIGS. 6 and 7. FIG. 6 shows a block diagram of a structure of a management apparatus 600 for traffic management according to an embodiment of the present invention.

The management device 600 includes a receiving module 610 and an allocation module 620. The receiving module 610 is configured to receive the notification of the request token sent by the at least two boards, and the number of tokens requested by each board corresponds to the number of packets to be transmitted in the queue of the to-be-scheduled message in the board. The allocating module 620 can be configured to allocate a token to the to-be-scheduled message queue according to the number of requested tokens, so that the board transmits the packet in the message queue to be scheduled according to the allocated token.

For the above-mentioned and other operations and/or functions of the receiving module 610 and the allocating module 620 of the management device 600, reference may be made to S110 and S120 of the method 100 of the traffic management of FIG. 1 above. To avoid repetition, details are not described herein again.

The management apparatus according to the embodiment of the present invention may allocate a token based on the notification of the plurality of board request tokens, so as to control the packet transmission of the board through the allocation of the token, so that the traffic in the board that originally performs traffic management independently Unified, centralized scheduling can be achieved, unlike the prior art, the traffic in each board is managed separately, independently, and isolated. Therefore, by using the management device for centralized traffic management, it is possible to uniformly and efficiently manage data streams that may be associated with each other on different boards, thereby satisfying the requirements of traffic management.

Fig. 7 is a block diagram showing the structure of a management apparatus 700 for traffic management according to an embodiment of the present invention. The receiving module 710 and the assigning module 720 in the management device 700 are substantially the same as the receiving module 610 and the assigning module 620 in the managing device 600 of FIG.

According to an embodiment of the present invention, the allocating module 720 can be configured to allocate a token to the to-be-scheduled message queue based on a priority scheduling policy or a load balancing policy.

According to one embodiment of the invention, the allocation module 720 can be configured to periodically assign tokens to the queue of messages to be scheduled.

Management device 700 may also include a stop module 730, in accordance with an embodiment of the present invention. The stop module 730 can be configured to stop assigning tokens to the queue of pending messages when the number of assigned tokens is equal to the number of tokens requested.

For the above-mentioned and other operations and/or functions of the allocation module 720 and the stop module 730, reference may be made to S120 of the method 100 of the traffic management of FIG. 1 and S230 of the method 200 of the traffic management of FIG. 2, in order to avoid redundancy, details are not described herein again. .

The scheduling module performs the scheduling based on the priority scheduling policy, so that the important packets, that is, the packets stored in the queue with the highest priority, are preferentially scheduled. By assigning module base The load balancing policy is used for scheduling, so that the queues of the packets to be scheduled can be uniformly scheduled, so that the traffic of each board can be uniformly balanced, and the traffic in one board is always in a waiting state and cannot be transmitted. . The token is periodically allocated by the distribution module, so that when the management device cannot satisfy the requested number of tokens at one time, the token can be flexibly allocated by sending the token multiple times to satisfy the predetermined scheduling policy. By stopping the module, it is possible to determine when to stop the assignment of the token.

Those skilled in the art will appreciate that the various method steps and elements described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both, in order to clearly illustrate the interoperability of hardware and software. The steps and composition of the various embodiments have been generally described in terms of function in the above description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods for implementing the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present invention.

The method steps described in connection with the embodiments disclosed herein may be implemented in hardware, a software program executed by a processor, or a combination of both. Software programs can be placed in random access memory (RAM), memory, read only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM or technology Any other form of storage medium known.

While some embodiments of the present invention have been shown and described, it will be understood by those skilled in the art It is within the scope of the invention.

Claims

Rights request

A method for traffic management, comprising:

Receiving the notification of the request token sent by the at least two boards, the number of tokens requested by each board corresponds to the number of packets to be transmitted in the queue of the to-be-scheduled message in the board;

Assigning a token to the to-be-scheduled message queue according to the number of requested tokens, so that the board root

The method according to claim 1, wherein the assigning a token to the to-be-scheduled message queue includes: assigning a command to the to-be-scheduled message queue based on a priority scheduling policy or a load balancing policy brand.

The method according to claim 1, wherein the assigning a token to the to-be-scheduled message queue comprises: periodically allocating a token to the to-be-scheduled queue.

4. The method according to claim 1, further comprising:

When the number of assigned tokens is equal to the requested number of tokens, the allocation of tokens to the to-be-scheduled message queue is stopped.

The method according to claim 1, wherein the board is configured according to the token bucket technology, and the board is configured to send packets in the queue to be scheduled according to the allocated token. Transfer.

6. The method according to claim 1, further comprising:

If the board determines that the number of assigned tokens is less than the number of tokens requested, then the notification of the request token is sent again.

A management device for traffic management, comprising:

a receiving module, configured to receive a notification of a request token sent by at least two boards, where the number of tokens requested by each board corresponds to the number of packets to be transmitted in the queue of the to-be-scheduled message in the board; And assigning a token to the to-be-scheduled message queue according to the requested number of tokens, so that the board transmits the packet in the to-be-scheduled message queue according to the allocated token.

The management device according to claim 7, wherein the allocation module is configured to allocate a token to the to-be-scheduled message queue based on a priority scheduling policy or a load balancing policy.

The management device according to claim 7, wherein the allocating module is configured to periodically allocate a token to the to-be-scheduled message queue.

The management device according to claim 7, further comprising: a stopping module, configured to stop to the queue to be scheduled when the number of assigned tokens is equal to the number of requested tokens Assign a token.