CN113194037A

CN113194037A - Traffic scheduling method and device

Info

Publication number: CN113194037A
Application number: CN202110347791.5A
Authority: CN
Inventors: 蒋文栋
Original assignee: New H3C Big Data Technologies Co Ltd
Current assignee: New H3C Big Data Technologies Co Ltd
Priority date: 2021-03-31
Filing date: 2021-03-31
Publication date: 2021-07-30
Anticipated expiration: 2041-03-31
Also published as: CN113194037B

Abstract

The present specification provides a traffic scheduling method and apparatus, where the method includes: after the configuration of the path to be deployed is issued to the network device, if the controller receives new service flow data or link data, the real-time bandwidth of the link is obtained according to the service flow data and link data newly reported by the network device, and the real-time bandwidth of the link is predicted.

Description

Traffic scheduling method and device

Technical Field

The present disclosure relates to the field of communications technologies, and in particular, to a traffic scheduling method and apparatus.

Background

In recent years, SDN (Software Defined Network) technology is widely used in various fields and various user actual networks. The specific techniques and solutions that SDN controllers need to use vary from one domain to another and from one user network to another.

Several elements of concern for SDN controllers are:

(1) and (4) node attribute: the method comprises the steps of including basic information and interface list information of network equipment;

(2) and link attribute: including basic, static, and traffic attributes of the link.

Wherein, the basic attributes of the link include: a source device and an interface corresponding to the link, and a destination device and an interface corresponding to the link;

the static properties of the link include: the method comprises the following steps of allocating bandwidth, Cost and attribute marks;

the dynamic properties of the link include: delay, jitter, packet loss rate;

the service attributes include: characteristics of the traffic, the start point, end point, real-time bandwidth, routing constraints (e.g., path quality, path bandwidth, affinity attributes, COST, etc.), current path through which the traffic flows.

With the development of services, scheduling techniques are continuously improved, for example: the controller supports technologies such as batch calculation of paths and asynchronous path distribution according to network element batches, and the execution performance of flow scheduling is continuously improved. In an actual production environment, due to the limitation of the performance of the equipment, the frequency of acquiring and scheduling data, which is often set by a network management system of a user, is relatively low. Because there is a time difference between the cycle of acquiring the scheduling data on the network device by the network management system and the time of issuing the traffic adjustment strategy and the time of actually adjusting the traffic, the problem of over-scheduling or wrong scheduling may be caused.

Disclosure of Invention

In order to overcome the problems in the related art, the present specification provides a traffic scheduling method and apparatus.

According to a first aspect of embodiments herein, there is provided a traffic scheduling method, the method including:

receiving service flow data and link data of network equipment;

predicting the real-time bandwidth of the link according to the currently received service flow data and link data and calculating a new deployment path;

issuing the configuration of the new path to be deployed to the network equipment;

if new service flow data or link data is received, updating the predicted link real-time bandwidth according to the newly received service flow data and link data;

and determining whether the service flow needs to be scheduled according to the predicted link real-time bandwidth.

Optionally, predicting the real-time bandwidth of the link according to the currently received service flow data and link data includes:

if the adjustment type of the service flow in the currently deployed link is the call-out type, the prediction of the link real-time bandwidth can be performed according to the following formula:

the real-time bandwidth prediction LCBWF of the link is equal to the real-time bandwidth LCBW of the link, namely the real-time bandwidth FBW of the service flow;

if the adjustment type of the service flow in the currently deployed link is the call-in type, the prediction of the link real-time bandwidth can be performed according to the following formula:

the real-time bandwidth prediction LCBWF of the link is the real-time bandwidth of the link LCBW + the real-time bandwidth of the traffic flow FBW.

Optionally, if new service flow data or link data is received, updating the predicted link real-time bandwidth according to the newly received service flow data and link data, including:

if the adjustment type of the service flow in the currently deployed link is the call-out type, updating the predicted link real-time bandwidth by subtracting the bandwidth changed by the service flow from the predicted link real-time bandwidth;

and if the adjustment type of the service flow in the currently deployed link is the call-in type, updating the predicted link real-time bandwidth by using the predicted link real-time bandwidth and the bandwidth changed by the service flow.

predicting the real-time bandwidth of a link, namely predicting the real-time bandwidth of a last link, namely predicting the real-time bandwidth of a service flow;

and predicting the real-time bandwidth of the link, namely predicting the real-time bandwidth of the last link and predicting the real-time bandwidth of the service flow.

Optionally, if new link data is received, updating the predicted link real-time bandwidth according to the newly received service flow data and the link data, including:

determining the total time of the service flow staying on the current deployment link and the adjustment type of the service flow on the current deployment link recorded last time;

if the adjustment type of the latest service flow is the call-in type, calculating the size of the service flow corresponding to the service flow when the service flow does not stay on the current deployment link according to the total stay time and the bandwidth of the current service flow, and adding the size compensation of the service flow corresponding to the non-stay time into the real-time bandwidth of the latest predicted link;

if the adjustment type of the latest service flow is the call-out type, calculating the size of the service flow corresponding to the service flow when the service flow stays on the current deployment link according to the total stay time and the bandwidth of the current service flow, and eliminating the size of the service flow corresponding to the stay time in the latest predicted real-time bandwidth of the link.

Optionally, determining whether to schedule the service flow according to the predicted link real-time bandwidth includes:

if the real-time bandwidth of the link is determined to be larger than the allocable bandwidth of the link according to the current link data, and the predicted real-time bandwidth of the link is smaller than the allocable bandwidth of the link, after waiting for the preset time, adjusting the current deployed path of the service flow by using the newly-uploaded link data and the service flow data.

Optionally, after waiting for the preset duration, adjusting the currently deployed path of the service flow by using the newly uploaded link data and the newly uploaded service flow data includes:

and after waiting for the arrival of the link data and the service flow data in the next period, adjusting the currently deployed path of the service flow by using the newly-uploaded link data and the newly-uploaded service flow data.

According to a second aspect of embodiments herein, there is provided a traffic scheduling apparatus, the apparatus comprising:

the receiving module is used for receiving the service flow data and the link data of the network equipment;

the prediction module is used for predicting the real-time bandwidth of the link according to the currently received service flow data and link data and calculating a new deployment path;

the issuing module is used for issuing the configuration of the new path to be deployed to the network equipment;

if the receiving module receives new service flow data or link data, the predicting module updates the predicted link real-time bandwidth according to the newly received service flow data and link data;

the prediction module is further configured to determine whether a service flow needs to be scheduled according to the predicted link real-time bandwidth.

Optionally, the prediction module is specifically configured to, if the adjustment type of the currently deployed link of the service flow is a call-out type, predict the real-time bandwidth of the link according to the following formula:

Optionally, the prediction module is specifically configured to, if the adjustment type of the service flow in the currently deployed link is a call-out type, update the predicted link real-time bandwidth by subtracting the bandwidth of the service flow change from the predicted link real-time bandwidth;

Optionally, the prediction module is specifically configured to determine a total duration of the service flow staying on the currently deployed link and a last recorded adjustment type of the service flow on the currently deployed link;

Optionally, the prediction module is specifically configured to, if it is determined that the real-time bandwidth of the link is greater than the allocable bandwidth of the link according to the current link data and the predicted real-time bandwidth of the link is less than the allocable bandwidth of the link, trigger, after waiting for a preset duration, to adjust the currently deployed path of the service flow by using the newly-uploaded link data and the service flow data.

Optionally, the prediction module is specifically configured to, after waiting for the arrival of both the link data and the traffic flow data in the next period, adjust a currently deployed path of the traffic flow by using the newly-uploaded link data and the newly-uploaded traffic flow data.

The technical scheme provided by the embodiment of the specification can have the following beneficial effects: in the method of the present specification, after the configuration of the path to be deployed is issued to the network device, if the controller receives new service flow data or link data, the controller obtains the real-time bandwidth of the link according to the service flow data and the link data newly reported by the network device, and predicts the real-time bandwidth of the link, and compared with predicting the real-time bandwidth of the link only by using link data, the present specification updates the predicted real-time bandwidth of the link according to the service flow data, so that the prediction of the real-time bandwidth of the link is more accurate, and on the premise that the prediction of the real-time bandwidth of the link is more accurate, it can be determined whether the subsequent adjustment of the service flow needs to be continued, thereby avoiding some problems of wrong scheduling or over scheduling.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the specification.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present specification and together with the description, serve to explain the principles of the specification.

Fig. 1-1 is a schematic view of traffic scheduling in the related art provided in the present specification;

fig. 1-2 are schematic views of another traffic scheduling in the related art provided in the present specification;

fig. 2 is a schematic diagram of a network architecture provided by an embodiment of the present description;

fig. 3 is a flowchart schematically illustrating a traffic scheduling method provided in an embodiment of the present specification;

fig. 4 is a schematic diagram of a collection period of traffic flow data and link data provided by an embodiment of the present specification;

fig. 5 is a schematic diagram of traffic scheduling provided by an embodiment of the present specification;

fig. 6 is a flowchart illustrating a traffic scheduling method according to another embodiment of the present disclosure;

fig. 7 is a schematic diagram of a traffic scheduling apparatus according to another embodiment of the present disclosure;

fig. 8 is a schematic structural diagram of a controller according to an embodiment of the present disclosure.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the specification, as detailed in the appended claims.

In the related art, fig. 1-1 shows a network architecture schematic diagram, as shown in fig. 1-1, if there are 100 user traffic flows Flow 1-100, the initial bandwidth of each user traffic Flow is 5M, and these flows are forwarded on the shortest path a- > B- > D- > F, if the flows of Flow1-Flow100 suddenly increase to 20M at this time, because the total bandwidth of the user traffic flows at this time exceeds the allocable bandwidths of link B- > D and link D- > F, the link B- > D and link D- > F trigger the adjustment of the packet loss rate and the forwarding path. If the period for acquiring the scheduling parameters by the controller is 1 minute, 10 streams are scheduled once, each adjustment needs to take 0.1 second, and the controller cannot judge the reason causing the path packet loss (for example, it cannot judge whether the current service stream bandwidth exceeds the packet loss caused by the allocable bandwidth of the path or the link quality itself is poor), so that the controller can schedule all the user service traffic to other paths and then terminate the scheduling, thereby generating the problem of over-scheduling.

In another possible case, based on the example of fig. 1-2, as shown in fig. 1-2, if the background traffic of the path B- > C- > F is 500M, the background traffic is traffic that is not managed by the controller, and the size of the traffic in the production environment varies irregularly. If the controller adjusts the Flow1-Flow100 originally forwarded in the path B- > D- > F to other paths for forwarding, the controller needs to estimate the link real-time bandwidth corresponding to other candidate paths, and further determines whether the candidate path meets the bandwidth constraint condition after the user traffic is adjusted to the candidate path. For example, if the current candidate path is a- > B- > C- > F, the controller performs link real-time bandwidth prediction on the paths constituting the candidate path.

However, the controller cannot judge the composition of the current traffic collection value of the link, the network device counts link data, a statistical period exists, the controller collects traffic conditions of the previous statistical period, the controller estimates the real-time bandwidth of the link by using the link data collected before, and at this time, since the traffic adjusted to B- > C, C- > F is not counted yet, the real-time bandwidth of the link adjusted to B- > C, C- > F is wrongly refreshed to the bandwidth of background traffic, namely 500M.

The controller continuously adjusts the traffic of more than 500M to B- > C, C- > F, which will result in the loss of service.

And after detecting the path packet loss rate data again, the controller triggers the path adjustment of the service flow again, and finally the partial flow is adjusted to B- > E- > F.

Thereby possibly creating a wrong scheduling of the path.

In the traffic scheduling method provided in this specification, the real-time bandwidth of the link is predicted by the traffic flow data of the network device, and the predicted real-time bandwidth of the link is estimated when the traffic flow data sent in a new period is received or the link data is received.

Before describing the traffic scheduling method provided in the present specification, some basic concepts involved in the present invention will be described.

The fbw (flow bandwidth) is a bandwidth of a service flow of a user, and the controller actively acquires the bandwidth or periodically reports the bandwidth to the controller by the device.

LMRBW (Link Max Reserve BandWidth) is the maximum allocable bandwidth of a Link, networking basic configuration is carried out, and a user reports to a controller through a Border Gateway Protocol-Link State BGP-LS (Border Gateway Protocol Link-State) technology according to the configuration of an actual network condition.

The LCBW (LinkCurrentBandWidth) is the real-time bandwidth of the link, and the controller actively acquires or periodically reports the bandwidth to the controller.

The LRBW (link reservedbandwidth) is the remaining allocable bandwidth of the link, and the calculation manner of the remaining allocable bandwidth of the link may be determined by subtracting the real-time bandwidth of the link from the allocable bandwidth of the link in this embodiment, specifically, the LRBW is LMRBW-LCBW, where the LRBW is calculated and maintained by the controller.

In addition, measuring the quality of the path through which the traffic flows may include multiple aspects, on one hand, each of the traffic flows has its own constraint condition, for example, some important traffic has a packet loss rate smaller than a certain threshold and the path through which the traffic flows cannot exceed a certain number of hops, and on the other hand, the quality of the link itself, for example, whether the allocable bandwidth is sufficient or not, and the like. Therefore, the data reported by the network device to the controller (or actively collected by the controller) in this specification relates to two types of data, one type of data related to traffic flow (flow) and the other type of data related to link (link).

Data related to traffic flow

The data related to the service flow includes data reported by the network device and data maintained by the controller.

The data of the service flow reported by the network device includes:

the basic information of the traffic flow of the FINFO (flow info) user includes a tunnel type, a tunnel number, and the like. The tunnel type may be SR TE (Segment Routing Traffic Engineering), SR Policy (Segment Routing Policy), SRV6 Policy (SR-TE Policy based on IPv 6).

Fbwct (flow Bandwidth Collection time) acquisition time of user traffic Bandwidth. The acquisition time does not refer to the time acquired by the controller or the time for pushing the devices in batches, the network device periodically counts the bandwidth value of the network device, and the FBWCT is the time recorded by the network device after each counting is finished.

Fbwci (flow Bandwidth Collection interval) Bandwidth Collection interval of user traffic.

The bandwidth value of the service flow of the fbw (flow bandwidth) user is actively acquired by the controller or periodically reported to the controller by the device.

The data of the service flow maintained by the controller includes the following data besides the data of the service flow reported by the network device:

fpp (flow Pre path) represents the path where the user traffic is to be deployed.

Fat (flow Adjust time): the controller will adjust the path of the flow, and after calculating a new path, the controller will record the time, which is the adjustment time of the FAT path. At this time, the controller gives a path just after the calculation, a newly calculated path to be deployed is not yet deployed to the network device, and the path to be deployed is in the batch deployment queue. The controller records the corresponding relation between the flow adjustment time FAT and the path FPP to be deployed of the user service. Fig. 4 shows an example in which the controller records the FAT after calculating the path of the traffic. After the controller calculates the path, it will issue the newly calculated path to be deployed to the network device.

Fcp (flow Current path) represents the Current path of the issued deployment of user traffic.

After the FDT (flow delivery time) controller issues the path to be deployed to the network device, the network device sends a response that the path has been deployed to the controller, and the controller records the time when the response is received, that is, the deployment time FDT of the path, where fig. 4 shows an example where the controller records the FDT. After the controller issues the path to be deployed, the FPP of the path to be deployed is updated to the FCP of the path already deployed, and the controller records the corresponding relationship between the FDT and the FCP, that is, records the path already deployed and the time for completing the path deployment.

(II) Link-related data

The link data reported by the network device includes:

the data reported or collected by the link Dynamic Info collection link may include: any one or more of LINFO, LDICT, LDICI, LDI.

Wherein, LINFO (Link info) is link basic information, including: source and destination IP addresses at both ends of the link.

Time of acquisition of LDICT (Link Dynamic Info Collection time) link data. The acquisition time does not refer to the time acquired by the controller or the time of batch pushing of the equipment, the network equipment can periodically acquire link data, for example, dynamic attributes of the link are acquired, and the LDICT refers to the time recorded after the network equipment finishes acquiring the link data each time. Fig. 4 shows an example of the link data record LDICT collected by the network device.

An acquisition interval (period) of ldici (link Dynamic Info Collection interval) link data.

LDI (Link Dynamic info) Link Dynamic attributes, including: LCBW, LPL, LD;

the LCBW (Link Current BandWidth) is the real-time bandwidth of a link reported by the equipment, and the controller actively acquires the bandwidth or periodically reports the bandwidth to the controller by the equipment;

lpl (link Packet lost) is a link Packet loss rate;

LD (Link delay) is the link delay.

The link data maintained by the controller includes:

the detailed information of the LDINFO (Link Detail info) link comprises the following steps: the source IP address and the destination IP address corresponding to the link, and other remarkable information of the link.

LMRBW (Link Max Reserve BandWidth) is the maximum allocable bandwidth of the link, the networking basic configuration is carried out, and a user reports the configuration according to the actual network condition to the controller through BGP-LS technology.

LC (Link cost) is the link overhead.

The time of acquisition of previous link data of a LLDICT (Link Last Dynamic Info Collection time) link.

The controller predicts the link real-time Bandwidth according to the link real-time Bandwidth value, the path service to be deployed and the deployed path service, and the value is used as the predicted value of the link Bandwidth for flow scheduling.

An LPLF (Link Packet Lost Forcast) link Packet loss rate predicted value is predicted according to the relationship between the maximum allocable bandwidth LMRBW and the LCBWF of the link. How to predict will be described in detail in the following examples.

Lfdh (link Flow delivery history) records that all services in the service Flow acquisition period (after LLDICT) call out the link or call in the history of the link. Each piece of history information includes: basic information of traffic flow FINFO, adjustment type (call-out or call-in), adjustment time of path FAT.

LFPD (Link Flow Pre delivery) records all deployed traffic flows that are tuned away or tuned into the link.

Example one

After the basic concept is introduced, the traffic scheduling method provided in this specification will be described in detail. Fig. 2 is a schematic diagram of a network architecture provided in this embodiment, and the method provided in this embodiment is described in this embodiment by taking an example of scheduling a service flow in the networking architecture shown in fig. 2. Fig. 3 is a flowchart illustrating a traffic scheduling method according to this embodiment. The method may be applied to a controller, network management software, etc., and the type of hardware device, software, etc. for performing the method is not limited. The present embodiment is described by taking the method shown in fig. 3 executed by the controller as an example.

As shown in fig. 3, the method includes:

step 301, receiving network device traffic flow data and link data.

The traffic flow data and the link data have already been introduced in the above description of the basic concept, and are not described herein again.

Step 303, predicting the real-time bandwidth of the link according to the currently received service flow data and link data, and calculating a new deployment path.

In this embodiment, taking 100 traffic flows flow1-flow100 forwarded between network device a and network device F shown in fig. 2 as an example, if the initial bandwidths of flow1-flow100 are all 5M, where the maximum allocable bandwidth of each link, the cost of each link, and the like may be shown in fig. 2, and are not described herein again. Traffic flows 1 and flow100 are all forwarded on shortest path A- > B- > D- > F, that is, the currently deployed path for traffic flows 1 and flow100 is A- > B- > D- > F.

As described above, the controller will continue to receive two types of data sent by the network device: link related data and traffic flow related data. From the two types of dashed lines in fig. 4, it can be seen that the periods for the network device to collect the two types of data may be different, and the periods for receiving the two types of data sent by the network device are different for the controller.

Aiming at data related to service flows sent by network equipment, the controller checks whether the bandwidth FBW and the packet loss rate of each service flow meet requirements or not; the controller checks whether the real-time bandwidth of the link on each link exceeds a preset proportion of the allocable bandwidth for the link related data sent by the network device, and if the real-time bandwidth of the link exceeds the preset proportion, the traffic flow on the link needs to be adjusted to other links. For example, if the real-time bandwidth of link2 is 900M, and if the predetermined ratio is 80%, the real-time bandwidth 900M already exceeds 80% of the allocable bandwidth 1000M of link2, so 100M of traffic needs to be called out of link 2.

The new path to be deployed calculated by the controller may be determined according to a principle that the cost of the path is minimum, or according to a principle that the remaining allocable bandwidth is maximum, or the like. Specifically, the manner of determining the new path to be deployed at the beginning may be determined in any manner.

The prediction of the real-time bandwidth of the link can be performed according to the adjustment type of the traffic flow on the link, for example, if the link2 is called out from flow1 to flow15, the prediction of the link real-time bandwidth of the link2 can be performed according to the currently acquired link real-time bandwidth minus the total bandwidth of the traffic flow of the link2 adjusted out of the link; if flows 11-15 are tuned into link4, the prediction of the link real-time bandwidth for link4 can be predicted according to the currently acquired link real-time bandwidth plus the total bandwidth of the traffic flow tuned into link 4.

Of course, there may be different ways to predict the real-time bandwidth of the link. Other ways of predicting the real-time bandwidth of the link will be further described in the following embodiments.

Step 305, the new configuration of the path to be deployed is sent to the network device.

Step 307, if new traffic flow data or link data is received, updating the predicted link real-time bandwidth according to the newly received traffic flow data and link data.

Therefore, the controller can update the predicted real-time bandwidth of the link according to the link data and the traffic flow data reported in the new period.

Step 309, determining whether the service flow needs to be scheduled according to the predicted link real-time bandwidth.

In the related art, a problem that may occur is that a controller has issued a path to be deployed to a network device, the network device has actually adjusted a link to which a service flow is actually forwarded, but the network device has not reported newly acquired link data and service flow data, so that the controller always calculates using old link data and service flow data, and actually, 100 service flows only need to adjust 20 service flows to other links, but when the controller performs path calculation, the controller continuously performs trigger adjustment to adjust the service flows back and forth on different paths, and a problem of wrong scheduling occurs because the link data and the service flow data are old data.

In the method of this specification, after the configuration of the path to be deployed is issued to the network device, if the controller receives new service flow data or link data, the controller obtains the real-time bandwidth of the link according to the service flow data and the link data newly reported by the network device, and predicts the real-time bandwidth of the link.

For step 309, one possible implementation manner for determining whether the service flow needs to be scheduled according to the predicted link real-time bandwidth is as follows:

and if the real-time bandwidth of the link is determined to be larger than the allocable bandwidth of the link according to the link data and the predicted real-time bandwidth of the link is smaller than the allocable bandwidth of the link, waiting for the arrival of the link data and the service flow data in the next period, and then adjusting the currently deployed path of the service flow by using the newly-uploaded link data and the newly-uploaded service flow data.

If the link real-time bandwidth acquired by the controller in the current period is greater than the allocable bandwidth of the link, but the predicted link real-time bandwidth is less than the allocable bandwidth of the link, it indicates that it may not be necessary to adjust the service flow to the newly calculated path to be deployed, so the controller may perform silence, that is, after the link data and the service flow data in the next period both arrive, it adjusts the path currently deployed for the service flow.

Taking fig. 4 as an example, if the time at this time is FBWCT2 in fig. 4, the acquisition period of the link data corresponding to the current time is LDICT2, the next period for acquiring the traffic data is FBWCT3, but the next period for the acquisition period of the link data is LDICT3, so that after the link data and the traffic data in the next period indicated in step 309 arrive, the controller needs to adjust the traffic after the time of LDICT3 arrives.

The length of controller silent waiting is MAX (FBWCT)_{Current period of time},LDICT_{Current period of time}) Current time instant + MAX (LDICI, FBWCI). Wherein, FBWCT_{Current period of time}Refers to the collection time of the first service flow data after the current time, LDICT_{Current period of time}Refers to the acquisition time of the first link data after the current time.

If the current time is any time T between FBWCT2 and FBWCT3, then FBWCT_{Current period of time}The first service flow data acquisition time after the time T is FBWCT 3; LDICT_{Current period of time}The first link data acquisition time after the time T is the LDICT 2. In the example of fig. 4, the silent waiting time of the controller is LDICT2-T + LDICI.

If the controller determines that the real-time bandwidth of the link is greater than the allocable bandwidth of the link according to the current link data (which may be newly received or may be received in the last period), but if the predicted real-time bandwidth of the link is smaller than the allocable bandwidth of the link, it is indicated that it may not be necessary to adjust the traffic flow to the newly calculated path to be deployed at this time, and the controller performs the path adjustment by using the link data and the traffic flow data newly sent by the network device in a waiting manner until the link data and the traffic flow data in the next period arrive, so that the situation that the bandwidth of the traffic flow is increased suddenly can be avoided because the controller does not acquire the final traffic flow bandwidth.

Example two

In order to better understand the method provided by the first embodiment, the present embodiment further describes the method of the first embodiment by way of specific examples.

Specifically, as shown in fig. 6, the method provided in this embodiment specifically includes:

step 401, receiving the service flow data and the link data sent by the network device, and determining whether a path currently deployed for the service flow needs to be adjusted.

One example is as follows:

for example, for the case where both the link data and the traffic flow data are the first acquisition cycle, in the initial state, the link information maintained on the controller may be as shown in table 1-1:

wherein, in conjunction with table 1-1 and fig. 2, Link1 represents a Link between network device a and network device B, Link2 represents a Link between network devices B and D, Link3 represents a Link between network devices D and F, Link4 represents a Link between network devices B and C, Link5 represents a Link between network devices C and F, Link6 represents a Link between network devices B and E, and Link7 represents a Link between network devices E and F;

the maximum allocable bandwidth and cost of each link are shown in table 1-1, where LLDICT is the acquisition time of the last link data recorded by the controller, as shown in fig. 4, if the current acquisition time is LDICT3, the acquisition time of the last link data at the current time is LDICT 2; if the current acquisition time is LDICT2, the acquisition time of the last link data at the current time is LDICT 1.

The real-time bandwidth prediction LCBWF of each link is determined according to the calculation of the controller, and it is determined whether there is a traffic flow that is tuned away from the link, and since the initial state, that is, the first LDICT of the data of each link and the data of the traffic flow is taken as an example in this embodiment, the real-time bandwidth prediction LCBWF of each link is equal to the current real-time bandwidth LCBW of the link; in addition, because the real-time bandwidth LCBW of the current link of each link is smaller than the allocable bandwidth LMRBW of the link, and the packet loss rate of the currently acquired link is 0, the prediction of the packet loss rate is also LPLF which is 0; moreover, after the LLDICT, there is no traffic flow called out or called in each link, so that the records of the LFDH and the LFDH are null (null), and null represents that there is no traffic flow called out or called in the link; the remaining allocable bandwidth LRBW of the link is determined by LMRBW-LCBW.

TABLE 1-1

Link identification

LMRBW

LC

LLDICT

LDIC

LCBWF

LPLF

LFDH

LFPD

LRBW

Link1

3000M

1

T0-L1

LCBW:500M,LPL:0％,LDICT:T1-L1

500M

0％

Null

2500M

Link2

1000M

1

T0-L2

LCBW:500M,LPL:0％,LDICT:T1-L2

500M

0％

Null

500M

Link3

1000M

1

T0-L3

LCBW:500M,LPL:0％,LDICT:T1-L3

500M

0％

Null

500M

Link4

1000M

2

T0-L4

LCBW:500M,LPL:0％,LDICT:T1-L4

500M

0％

Null

500M

Link5

1000M

2

T0-L5

LCBW:500M,LPL:0％,LDICT:T1-L5

500M

0％

Null

500M

Link6

1000M

3

T0-L6

LCBW:0M,LPL:0％,LDICT:T1-L6

0M

0％

Null

1000M

Link7

1000M

3

T0-L7

LCBW:0M,LPL:0％,LDICT:T1-L7

0M

0％

Null

1000M

Meanwhile, the controller also maintains data related to the service flow, including a bandwidth FBW of the service flow, a collection time FBWCT for collecting the bandwidth of the service flow, an adjustment time FAT of a path, a path FPP to be deployed of the service flow, a deployment time FDT of the path, and a currently deployed path FCP, and specifically, an example is given in an exemplary manner in tables 1 to 2:

because the bandwidth of each service flow is 5M and does not exceed the carrying capacity of the bandwidth of each link included in the path a- > B- > C- > F, the path of the service flow does not need to be changed, and thus a recalculated path does not exist, that is, there is no path to be deployed FPP and there is no deployment time of the path to be deployed. Meanwhile, as the initial state is adopted, the service bandwidth information acquired last time does not exist in each service flow, so that the OFBW, the FAT and the FPP are null.

Tables 1 to 2

Service flow identification

OBFW

FBW

FBWCT

FAT

FPP

FDT

FCP

Flow1

Null

5M

T1-F1

Null

T0-F1

A->B->D->F

Flow2

Null

5M

T1-F2

Null

T0-F2

A->B->D->F

……

Flow100

Null

5M

T1-F100

Null

T0-F100

A->B->D->F

At this time, if the traffic flow1-flow100 suddenly increases to 20M at time T4, the controller receives the new link-related data reported by the network device again, and updates the content of the link data as shown in table 3-1:

specifically, if the traffic flow1-flow100 suddenly increases to 20M at time T4, the controller respectively collects data of each link at time T4-Li, and since there is no path adjustment before that, there is no link packet loss rate prediction and no deployment history of the link traffic flow, that is, the link packet loss rate prediction LPLF is null, and the history of the traffic flow tuned away from or tuned into the link is null. Wherein, i is a link identifier, and T4-Li is the time acquired by the ith link in the link acquisition period corresponding to T4. Different links may be the same or slightly different during the same acquisition period.

In addition, as the bandwidth of the service flow is increased rapidly, the data related to the service flow and the data related to the link collected by the controller are average values in a collection period, so that neither the packet loss rate of the collected link nor the bandwidth of the service flow is a final value of 20M. The real-time bandwidths LCBW of link1, link2 and link3 collected by the controller are all 1500M, link4, the real-time bandwidth of link5 is 500M, link6, the real-time bandwidth of link7 is 0M, link2 and the packet loss rate of link3 is 20 percent. The controller can calculate the LRBW according to the LMRBW and the LCBW of each link, and the LRBW of each link can be shown in a table 3-1.

TABLE 3-1

Link identification

LMRBW

LC

LLDICT

LDIC

LCBWF

LPLF

LFDH

LFPD

LRBW

Link1

3000M

1

T3-L1

LCBW:1500M,LPL:0％,LDICT:T4-L1

1500M

0％

Null

1500M

Link2

1000M

1

T3-L2

LCBW:1500M,LPL:0％,LDICT:T4-L2

1500M

20％

Null

0M

Link3

1000M

1

T3-L3

LCBW:1500M,LPL:0％,LDICT:T4-L3

1500M

20％

Null

0M

Link4

1000M

2

T3-L4

LCBW:500M,LPL:0％,LDICT:T4-L4

500M

0％

Null

500M

Link5

1000M

2

T3-L5

LCBW:500M,LPL:0％,LDICT:T4-L5

500M

0％

Null

500M

Link6

1000M

3

T3-L6

LCBW:0M,LPL:0％,LDICT:T4-L6

0M

0％

Null

1000M

Link7

1000M

3

T3-L7

LCBW:0M,LPL:0％,LDICT:T4-L7

0M

0％

Null

1000M

At the same time, the controller will collect traffic flow data, and thus, table 1-2 is updated as shown in table 3-2:

since the time of the last time the controller deployed the path a- > B- > D- > F to the network device did not change, the FDT corresponding to each traffic flow1-flow100 is still T0-F1 … … T0-F100.

TABLE 3-2

Service flow identification

OBFW

FBW

FBWCT

FAT

FPP

FDT

FCP

Flow1

5M

15M

T4-F1

Null

T0-F1

A->B->D->F

Flow2

5M

15M

T4-F2

Null

T0-F2

A->B->D->F

……

Flow100

5M

15M

T4-F100

Null

T0-F100

A->B->D->F

Step 403, if the adjustment is needed, determining and recording a new path to be deployed and an adjustment type of the service flow for each service flow according to the service flow data and the link data;

if the controller can determine that the link real-time bandwidth LCBW of link2 and link3 exceeds the assignable bandwidth LMRBW of the link according to table 3-1, or determines that the link2 and link3 need to be adjusted according to the packet loss rate of the link, the controller determines a new path to be deployed for each service flow.

The controller may further determine a traffic bandwidth that needs to be adjusted for the currently deployed link. In an implementation manner, the controller may adjust the traffic bandwidth of the link, in which the real-time bandwidth of the link exceeds the allocable bandwidth of the link by a preset proportion, out of the currently deployed link. For example, if the predetermined ratio is 80%, the bandwidth required to be adjusted for link2 is LCBW-LMRBW × predetermined ratio of 1500M-1000M × 0.8 of 700M. The link3 determines the adjusted bandwidth in a manner similar to the link2 and will not be described in further detail herein.

The new path to be deployed calculated by the controller may be determined according to a principle that the cost of the path is minimum, or according to a principle that the remaining allocable bandwidth is maximum, or the like. The specific way of determining the new path to be deployed is not within the scope of the discussion of the present specification, and any existing way of determining the path may be adopted.

Taking the principle that the cost of the controller according to the path is minimum as an example, the path re-determined by the controller is A- > B- > C- > F.

Continuing with the example above, the type of adjustment for the traffic flow may be determined for each traffic flow. Specifically, for each service flow, whether a record of tuning-away or tuning-in of the service flow exists on the currently deployed link and the adjusted link is calculated. If not (it is indicated that the current service flow is not scheduled in the current LDICT period), a tuning-away record of the current service flow may be recorded for the current deployment link, and the real-time bandwidths of the current deployment link and the new link to be deployed are predicted through step 405, so as to obtain the LCBWF corresponding to each link.

One example is as follows:

taking the current traffic flow as flow1 as an example, the controller queries table 3-1 to determine a current deployment link2 and link3 for flow1 and a record LFPD for tuning away or tuning into the link to be deployed link4 and link5, and it can be known from table 3-1 that no call-out or call-in record (LFPD is null) related to flow1 exists on link2 and link 3. Therefore, the call out event of flow1 can be recorded to the LFPDs corresponding to link2 and link 3.

And records the call in event of flow1 to the LFPD corresponding to link4 and link 5.

Step 405, link real-time bandwidth prediction is performed on the current deployment link and the link to be deployed corresponding to the new path to be deployed according to the adjustment type of the service flow.

It should be noted that, after the controller calculates the route to be deployed, the controller may issue the route to be deployed to the network device soon, but after the route to be deployed is issued to the network device, there may be no period in which the network device side immediately reaches the network device to collect the link data and the service flow data, and there may be no new link data and new service flow data reported to the controller. Therefore, the execution sequence of step 405 and step 407 is random, or not limited to a sequential order.

It should be noted that the adjustment types of the traffic flows include two aspects, that is, the adjustment type of the traffic flow on the current deployment path and the adjustment type of the traffic flow on the newly calculated path to be deployed.

For example, flow1 corresponds to links 2 and link3 of the current deployment path, and the result of the calculation by the controller is to call out the flow1 to links 2 and link3, so that the flow1 is on the links 2 and link3 corresponding to the current deployment path, and the adjustment type of the flow1 is call out; correspondingly, after the flow1 is called out, the controller calculates that the flow1 can be adjusted to the link4 and the link5 corresponding to the path to be deployed, and then the adjustment type of the flow1 is called in at the link4 and the link5 corresponding to the path to be deployed.

Continuing with the above example, from step 403, the callout type of flow1 on currently deployed links link2 and link3 is callout. The controller predicts the link real-time bandwidth of currently deployed links link2 and link3 according to the adjustment type of flow1, and the real-time bandwidth prediction LCBWF can be predicted by adopting the following formula:

for flow1, real-time bandwidth prediction LCBWF at link2 and link3 is 1500M-15M 1485M;

for flow2, real-time bandwidth prediction LCBWF 1485M-15M 1470M on link2 and link 3;

… … up to flow20, real-time bandwidth prediction LCBWF on link2 and link3 is 1200M;

… … up to flow47, real-time bandwidth prediction LCBWF on link2 and link3 ═ 795M; the real-time bandwidth prediction LCBWF at this time < LRMBW x preset ratio, at which time the calculation may be stopped for the call-out type links 2 and link 3.

Accordingly, flow1-flow20 was adjusted to link4 and link 5. The predictions for the real-time links on link4 and link5 are: LCBWF ═ real-time bandwidth FBW of LCBW + traffic flow;

when flow1 is adjusted to link4, LCBWF is 500M +15M 515;

… … flow2 is adjusted to link4, LCBWF is 800M;

LCBWF for Link5 is calculated similarly to Link 4. At this time, the predicted real-time bandwidths of the links 4 and 5 reach the preset proportion 80% of the link allocable bandwidth LMRBW, so that the traffic flow cannot be adjusted to the link4 and the link5 at this time.

Depending on the cost of the link, flow 21-47 are now considered adjusted to link6 and link 7.

Calculating LCBWF according to the real-time bandwidth FBW of the LCBWF + service flow for flow 21-flow 47 one by one, and finally, calculating the LCBWF as 405M; at this time, LCBWF corresponding to link6 and link7 < preset ratio of link assignable bandwidth LMRBW 80%, so that flows 21 to 47 can be adjusted to link6 and link 7.

The link information maintained at the controller is updated at this time as shown in tables 3-3:

tables 3 to 3

Step 407, the new configuration of the path to be deployed is issued to the network device.

And the controller transmits the calculated relevant configuration of the path to be deployed to the network equipment.

The information of the service flow stored in the controller is updated as shown in tables 3-4:

tables 3 to 4

Step 409, after the controller issues the new path to be deployed to the network device, if new traffic flow data or link data is received, the predicted link real-time bandwidth is updated according to the newly received traffic flow data and link data.

After the controller issues the newly calculated link to be deployed to the network device, when the acquisition cycle of the network device for the link data or the service flow data arrives, the network device sends the link data or the service flow data acquired in a new cycle to the controller.

As can be seen from fig. 4, the periods of collecting the link data and the traffic flow data by the network device are different, and therefore, the execution sequence of receiving the new traffic flow data and link data by the controller is not determined.

However, for the controller, whether the traffic data or the link data is received, the real-time bandwidth of the link predicted in the previous step 407 is updated.

Specifically, in step 409, the link real-time bandwidth may be updated as follows:

taking the example that the controller receives the traffic flow data first, at this time, the controller senses that the FBW of each traffic flow is 20M.

The bandwidth increased for one traffic flow is FBW-OFBW-20M-15M-5M.

Specifically, the LCBWF is updated in one possible case using step 4091:

step 4091, if the adjustment type of the service flow in the currently deployed link is a call-out type, updating the real-time bandwidth LCBWF of the link predicted before according to the bandwidth changed by the service flow.

In effect, this is a compensation mechanism for the real-time bandwidth LCBWF of this predicted link. Specifically, the following formula can be used for updating:

the updated LCBWF is the previously calculated LCBWF- (FBW-OFBW);

thus, the LCBWF for link2 and link3 is updated from 795M to 695M.

In another possible scenario, the LCBWF is updated with step 4092:

step 4092, if the adjustment type of the service flow in the currently deployed link is the call-in type, updating the predicted link real-time bandwidth by using the predicted link real-time bandwidth plus the bandwidth of the service flow change.

Updated LCBWF ═ previously calculated LCBWF + (FBW-OFBW);

and LCBWF of link4 and link5 is updated from 800M to 900M;

the LCBWF of Link6 and Link7 is updated from 405M to 605M.

After the link4 and the link5 update the predicted real-time bandwidth of the link according to the traffic flow data reported by the network equipment, the LCBWF of the link4 and the link5 is greater than 80% of the LMRBW, so that 100M traffic needs to be called out.

After updating the LCBWF according to

step

4091 or 4092, the steps 401 to 405 may be repeated, or the process of recalculating a new deployment path in step 303 may be performed.

Step 4011, determining whether the service flow needs to be scheduled according to the predicted link real-time bandwidth.

As can be seen from

steps

4091 or 4092 above, a traffic flow re-tuning in or out may be triggered after a LCBWF re-update. Before and after updating the LCBWF, the adaptation type for the same traffic flow may be completely different, so that further compensation updates may be made to the updated LCBWF at this time. Specifically, the updating of the LCBWF may include:

step 5093, determining the adjustment type of each service flow in the current period according to the service flow data received in the current period and the link data received last time.

Step 5094, if the adjustment type of the service flow in the currently deployed link is a call-out type, predicting the real-time bandwidth of the link according to the following formula:

and predicting the real-time bandwidth of the link, namely predicting the real-time bandwidth of the last link and predicting the real-time bandwidth of the service flow. And (4) wide.

Continuing from the above embodiment, it can be determined from the traffic flow data received in this period (bandwidth of each traffic flow is increased to 20M) and the link data received last time (table 3-3) that LCBWF of link4 and link5 is updated from 800M to 900M, and then 100M traffic needs to be tuned away from link4 and link5, so that the tuning type of each traffic flow can be determined.

Taking link1 as an example again, if link1 is determined to need to tune away link4 and link5 after recalculation, the controller queries locally stored records LFPD of the traffic flow tuned in or tuned away on each link, and if there are tuning in or out records of traffic flow1 in LFPD, if the adjustment type of traffic flow1 recorded by LFPD is the same as the adjustment type of traffic flow1 determined in the present period, no redundant operation is needed. If the adjustment type of the traffic flow1 recorded by the LFPD is opposite to the tune-away type of the traffic flow1 determined in the present period, the LCBWF is updated according to the hop-out type of the traffic flow determined in the present period.

Specifically, flow1 may be called into link4 as shown in tables 3-3, and this determination requires flow1 to be called out of link4, then the predicted link real-time bandwidth LCBWF for link4 may be updated according to the following formula:

the updated LCBWF is the previously calculated LCBWF-FBW;

or, in another embodiment, if the controller receives link data sent by the network device at this time, the predicted link real-time bandwidth may also be updated according to the link real-time bandwidth, and if the adjustment type of the service flow determined this time is a call-out type, the adjustment type may be updated by using the following formula:

LCBWF＝LCBW-FBW。

assuming that the adjustment type calculated previously by flow1 is call-out, and the call-out type of the present period is determined as call-in according to the traffic data received in the present period, the predicted link real-time bandwidth LCBWF can be updated according to the following formula:

LCBWF＝LCBWF+FBW；

or, in another embodiment, if the controller receives link data sent by the network device at this time, the predicted link real-time bandwidth is updated according to the link real-time bandwidth included in the link data, and if it is determined that the adjustment type of the service flow in this period is the call-in type, the adjustment type may be updated by using the following formula:

LCBWF＝LCBW+FBW。

the above is a detailed description of how the controller updates the LCBWF according to the traffic flow data.

The following is a further description of how the controller updates the LCBWF when it receives link data from the network device. Specifically, the updating, by the controller, the LCBWF according to the link data includes:

step 6091, determine the total length of time that the traffic flow stays on the currently deployed link and the adjustment type of the traffic flow on the currently deployed link recorded last time.

Fig. 5 shows a schematic diagram of traffic flow being brought in and out during a certain link data collection period. As can be seen from fig. 5, during a link data collection period, a traffic flow may be repeatedly called in and out, wherein the bold horizontal line shows the duration of time that the traffic flow is actually forwarded on a link.

Wherein, Ti-in represents the time when the service flow is called in on the currently deployed link, and Ti-out represents the time when the service flow is called out on the currently deployed link. Wherein the value of i is 1-n. tn-in represents the time when the traffic was last brought into the link and tn-out represents the time when the traffic was last brought out of the link.

Then, the controller may determine that the total duration T _ Sum _ In for which the traffic flow stays on the current deployment path is:

T_Sum_In＝(LDICT–tn-in)+SUM(ti-in–ti-out)+(t1-out-LLDICT)；

step 6092, if the adjustment type of the latest service flow is the call-in type, calculating the size of the service flow corresponding to the service flow when the service flow does not stay on the current deployment link according to the total stay time and the bandwidth of the current service flow, and adding the size of the service flow corresponding to the non-stay time to the latest predicted real-time bandwidth of the link in a compensation manner.

The type of adjustment of the last traffic flow is the type of adjustment of the last traffic flow in the period.

Taking fig. 5 as an example, if the adjustment type of the traffic flow at the last time is a call-In type, then the non-stay time of the traffic flow on the link currently deployed may be determined according to the total time length T _ Sum _ In of the traffic flow staying on the current deployment path and the acquisition period LDICI of the link data, and the proportion of the non-stay time length to the entire LDICI may be determined, for example, if the adjustment type of the flow1 for the last time of a certain link4 is a call-In type, and according to the proportion of the non-stay time length to the entire LDICI, it may be estimated how much traffic of the network device is not counted up to the bandwidth of link4, and since the final flow1 is called into link4 In the present cycle, it is estimated that the traffic bandwidth that does not stay on link4 In the next cycle will be link4, thereby predicting the real-time traffic bandwidth on link4 may be achieved.

Specifically, if the adjustment type of the last traffic flow is the call-in type, the LCBWF may be updated according to the following formula:

LCBWF＝LCBWF+((LDICI-T_Sum_In)/LDICI)×FBW；

step 6093, if the adjustment type of the latest service flow is the call-out type, calculating the size of the service flow corresponding to the service flow staying on the current deployment link according to the total staying duration and the bandwidth of the current service flow, and excluding the size of the service flow corresponding to the staying in the latest predicted real-time bandwidth of the link.

Similar to step 6092, if the type of adaptation of the last traffic flow is the call out type, the LCBWF may be updated according to the following formula:

LCBWF＝LCBWF-(T_Sum_In/LDICI)×FBW。

the above step 6092 or step 6093 is performed for each traffic flow, and finally, the update of the LCBWF of the link where all the traffic flows are located is achieved. In an optional implementation manner, if the LFDH corresponding to a certain traffic flow is null, no calculation is needed.

The above is an embodiment for updating the LCBWF according to the link data.

In addition, the controller needs to update the link data maintained by the controller after receiving the link data.

According to link data sent by a controller, acquiring a real-time bandwidth LCBW of a link and calculating an allocable bandwidth of the link and a packet loss rate LPL of the link; meanwhile, the relation between the LCBWF and the link assignable bandwidth LMRBW can be obtained by predicting the link real-time bandwidth according to the link data.

In one possible approach, if the real-time bandwidth of the LCBW link > the allocable bandwidth of the LMRBW link and the packet loss rate of the LPL link >0, and the link real-time bandwidth prediction value LCBWF < the allocable bandwidth of the link LMRBW, the link packet loss rate LPLF of the next period may be predicted to be 0.

In this case, the real-time bandwidth of the LCBW link is greater than the allocable bandwidth of the LMRBW link, but at a later time, the real-time bandwidth of the link is likely to be less than the allocable bandwidth of the link, and thus no traffic is rescheduled to other links. The path can be adjusted after the real data of the service flow is completely collected by the network equipment after the real data of the service flow is silenced for a period of time.

An optional implementation is given in the first implementation, and details are not described in this embodiment.

It should be noted that the manner of updating the LCBWF provided in the above embodiments may be updated in any one or more manners. Various updating manners may also be performed in series, for example,

step

4091 or 4092 is performed first, then step 5093 or 5094 is performed, and then step 6091 or 6092 is performed, however, the period of reporting the traffic flow data by the network device is different from the period of reporting the link data, and actually, step 6091 or 6092 may also be performed first, and then step 4091 or 4092 is performed.

How to combine the above embodiments and the order of execution are not limited in this specification, and the execution order of each step in all embodiments in this specification may be different without conflict. The present specification also does not limit the timing when the controller issues the path to be deployed.

EXAMPLE III

On the basis of the foregoing method embodiment, this specification provides a traffic scheduling apparatus, which may execute any traffic scheduling method provided in the foregoing first embodiment or second embodiment, specifically, fig. 7 is a schematic structural diagram of the traffic scheduling apparatus provided in this embodiment, and as shown in fig. 7, the apparatus includes:

a receiving module 701, configured to receive network device service flow data and link data;

a prediction module 702, configured to predict a real-time bandwidth of a link according to currently received service flow data and link data and calculate a new deployment path;

the issuing module 703 is configured to issue the configuration of the new path to be deployed to the network device;

if the receiving module 701 receives new service stream data or link data, the predicting module 702 updates the predicted link real-time bandwidth according to the newly received service stream data and link data;

the prediction module 702 is further configured to determine whether a service flow needs to be scheduled according to the predicted link real-time bandwidth.

Optionally, the prediction module 702 is specifically configured to, if the adjustment type of the currently deployed link of the service flow is a call-out type, predict the real-time bandwidth of the link according to the following formula:

Optionally, the prediction module 702 is specifically configured to, if the adjustment type of the currently deployed link of the service flow is a call-out type, update the predicted link real-time bandwidth by subtracting the bandwidth of the service flow change from the predicted link real-time bandwidth;

Optionally, the prediction module 702 is specifically configured to determine a total duration of the service flow staying on the currently deployed link and a last recorded adjustment type of the service flow on the currently deployed link;

Optionally, the prediction module 702 is specifically configured to, if it is determined that the real-time bandwidth of the link is greater than the allocable bandwidth of the link according to the current link data and the predicted real-time bandwidth of the link is less than the allocable bandwidth of the link, trigger, after waiting for a preset time period, to adjust the currently deployed path of the service flow by using the newly-uploaded link data and the service flow data.

Optionally, the prediction module 702 is specifically configured to, after waiting for the arrival of both the link data and the traffic flow data in the next period, adjust a currently deployed path of the traffic flow by using the newly uploaded link data and the newly uploaded traffic flow data.

For the traffic scheduling apparatus provided in this embodiment, specific execution processes of each module and achieved technical effects may refer to the method embodiment, and details are not described in this embodiment again.

The present specification further provides a controller 80, and fig. 8 is a schematic structural diagram of a controller provided in another embodiment of the present specification, as shown in fig. 8, the controller 80 includes a processor 801 and a memory 802,

the memory 802 is configured to store program instructions, the processor 801 is configured to call the program instructions stored in the memory, and when the processor 801 executes the program instructions stored in the memory 802, the processor is configured to execute the traffic scheduling method in the foregoing embodiments. Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a better understanding of the present invention. It will be understood by those skilled in the art that the present invention may be practiced without some of these specific details. In some instances, methods, procedures, components, and circuits that are well known to those skilled in the art have not been described in detail so as not to obscure the present invention.

In the embodiments provided in the present invention, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative and, for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, the functional modules in the embodiments of the present invention may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solution of the present invention or a part thereof, which essentially contributes to the prior art, can be embodied in the form of a software product, which is stored in a readable storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned readable storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A traffic scheduling method, comprising:

receiving service flow data and link data of network equipment;

2. The method of claim 1, wherein predicting the real-time bandwidth of the link based on the currently received traffic flow data and link data comprises:

if the adjustment type of the service flow in the currently deployed link is the call-out type, predicting the real-time bandwidth of the link according to the following formula:

if the adjustment type of the service flow in the currently deployed link is the call-in type, predicting the real-time bandwidth of the link according to the following formula:

3. The method of claim 2, wherein updating the predicted link real-time bandwidth based on the newly received traffic flow data and link data if new traffic flow data or link data is received comprises:

4. The method of claim 3, wherein updating the predicted link real-time bandwidth based on the newly received traffic flow data and link data if new traffic flow data or link data is received comprises:

5. The method according to any one of claims 1 to 4, wherein if new link data is received, updating the predicted link real-time bandwidth according to the newly received traffic flow data and link data comprises:

6. The method of claim 1, wherein determining whether a traffic flow needs to be scheduled based on the predicted link real-time bandwidth comprises:

7. The method according to claim 6, wherein the adjusting the currently deployed path of the traffic flow by using the newly uploaded link data and the traffic flow data after waiting for the preset time period comprises:

8. An apparatus for traffic scheduling, the apparatus comprising:

9. The apparatus according to claim 8, wherein the prediction module is specifically configured to predict the real-time bandwidth of the link according to the following formula if the adjustment type of the traffic flow in the currently deployed link is a call-out type:

10. The apparatus according to claim 9, wherein the prediction module is specifically configured to update the predicted link real-time bandwidth by subtracting a bandwidth of the traffic flow change from the predicted link real-time bandwidth if the adjustment type of the traffic flow on the currently deployed link is a call-out type;

11. The apparatus according to claim 10, wherein the prediction module is specifically configured to predict the real-time bandwidth of the link according to the following formula if the adjustment type of the traffic flow in the currently deployed link is a call-out type:

12. The apparatus according to any one of claims 8 to 11, wherein the prediction module is specifically configured to determine a total duration of a service flow staying on a currently deployed link and a last recorded adjustment type of the service flow on the currently deployed link;

13. The apparatus according to claim 8, wherein the prediction module is specifically configured to, if it is determined that the real-time bandwidth of the link is greater than the allocable bandwidth of the link according to the current link data and the predicted real-time bandwidth of the link is less than the allocable bandwidth of the link, trigger an adjustment of a currently deployed path of the traffic flow by using newly-uploaded link data and traffic flow data after waiting for a preset time.

14. The apparatus according to claim 13, wherein the prediction module is specifically configured to adjust a currently deployed path of the traffic flow by using the newly uploaded link data and traffic flow data after waiting for the arrival of both the link data and the traffic flow data in the next period.