WO2019052630A1

WO2019052630A1 - Data traffic management in a software defined networks

Info

Publication number: WO2019052630A1
Application number: PCT/EP2017/072852
Authority: WO
Inventors: Symeon CHOUVARDAS; Moez DRAIEF
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2017-09-12
Filing date: 2017-09-12
Publication date: 2019-03-21
Also published as: CN111095868A

Abstract

Provided is a procedure for managing data traffic in a software defined network, SDN. The procedure involves maintaining a plurality of models, a model characterizing an estimated temporal relationship between an event and data traffic to be handled within a network comprising the SDN, and forecasting data traffic to be handled by the SDN within a time span. The forecasting is based on mapping one or more upcoming aperiodic events to one or more of the models, if information on an upcoming aperiodic event is available, or data traffic reported by the SDN during a corresponding time span. The procedure also involves comparing the forecast data traffic to be handled by the SDN within the time span with data traffic reported by the SDN during the time span, wherein, if differences between the forecast data traffic and the reported data traffic are assessed as substantial, a reconfiguration of the SDN is initiated and/or a new model is generated or an existing model modified, wherein the new/modified model maps one or more current events to the reported data traffic.

Description

DATA TRAFFIC MANAGEMENT IN A SOFTWARE DEFINED NETWORKS

FIELD

The present disclosure relates to software defined networks (SDNs). In particular, the present disclosure relates to managing data traffic in SDNs. BACKGROUND

Network monitoring systems may provide information about data traffic in a network (network traffic). To this end a network monitoring system may comprise probes which are embedded into network devices or deployed as dedicated entities and collect statistics and measurements locally and a controller which collects aggregated statistics and measurements from the different probes. One of the major tasks of such a network monitoring system may be to forecast the network traffic for a given time span.

Traffic forecasting is at the heart of several problems of network management, such as: capacity expansion, traffic engineering, load balancing, anomaly detection, etc. Furthermore, accurate traffic forecasting allows for improved provisioning, planning and consequently, cost reduction. However, accurate traffic forecasting may be challenging since the variance and volatility of the data traffic may be high, due to the nature of the internet, as well as due to the presence of events or anomalies that affect the data traffic.

SUMMARY

According to a first aspect of the present invention, there is provided a system for managing data traffic in an SDN. The system comprises a knowledge unit, the knowledge unit being configured to maintain a plurality of models, a model characterizing an estimated temporal relationship between an event and data traffic to be handled within a network comprising the SDN, and a prediction unit. The prediction unit is configured to forecast data traffic to be handled by the SDN within a time span based on mapping one or more upcoming aperiodic events to one or more of the models, if information on an upcoming aperiodic event is available, or data traffic reported by the SDN during a corresponding time span. The system further comprises a live unit, the live unit being configured to compare the forecasted data traffic to be handled by the SDN within the time span with data traffic reported by the SDN during the time span, wherein, if differences between the forecast data traffic and the reported data traffic are assessed as substantial by the live unit, the live unit is configured to initiate a reconfiguration of the SDN, and/or cause the knowledge unit to generate a new model or modify an existing model, the new/modified model mapping one or more current events to the reported data traffic.

Thus, the system allows to accurately forecast data traffic over the links of the network, even in cases where large events take place, by mapping the contextual information to the available models. Furthermore, the system is capable of detecting an unexpected event/anomaly when it takes place. Moreover, a new model can be generated for each unexpected event/anomaly, e.g., for future use.

In a first possible implementation form of the system according to the first aspect, the live unit is configured to initiate a reconfiguration of the SDN by causing the knowledge unit to generate the new model or modify the existing model and providing the new/modified model to the prediction unit to forecast the data traffic based on the new/modified model.

Hence, the system is enabled to react to unexpected events/anomalies in real-time by detecting that an unexpected event/anomaly takes place and adapting the prediction based on a new/modified model that fits the unexpected event/anomaly. In a second possible implementation form of the system according to the first aspect, the reconfiguration of the SDN comprises a reconfiguration of one or more switches of the SDN by implementing new forwarding rules.

Accordingly, traffic congestion can be avoided ore reduced, even in cases of unexpected events/ anomalies. In a third possible implementation form of the system according to the first aspect, the system further comprises a database, the database storing information on the one or more upcoming events and/or one or more current events, wherein the information comprises at least one of a starting date, an end date, an estimated traffic pattern comprising a traffic volume and a traffic shape over a time window between the starting and the end date, and an event category.

Thus, the database allows to predict the shape of the upcoming data traffic.

In a fourth possible implementation form of the system according to the first aspect, the system is configured to mine the information from the net.

Hence, the system can forecast data traffic without human intervention and react in real-time to information becoming available on the net.

In a fifth possible implementation form of the system according to the first aspect, the model characterizes the estimated temporal relationship between the event and data traffic to be handled within the network by including parameters indicating a time instant relative to a course of the event at which a data traffic peak is to be expected.

Accordingly, the system allows to cope with data traffic peaks.

In a sixth possible implementation form of the system according to the first aspect, the model indicates data rates to be handled by SDN links at the time instant at which the data traffic peak is to be expected.

This allows to adapt the SDN links to the peak data rates that will be caused by upcoming events.

According to a second aspect of the present invention, there is provided a method for managing data traffic in an SDN. The method comprises maintaining a plurality of models in a knowledge database, a model characterizing an estimated temporal relationship between an event and data traffic to be handled within a network comprising the SDN, forecasting data traffic to be handled by the SDN within a time span, by mapping one or more upcoming aperiodic events to one or more of the models, if information on an upcoming aperiodic event is available, comparing the forecast data traffic to be handled by the SDN within the time span with data traffic reported by the SDN during the time span, and, depending on a result of the comparison, initiating a reconfiguration of the SDN.

Thus, the method allows accurately forecasting data traffic over the links of the network, even in cases where large events take place, by mapping the contextual information to the available models. Furthermore, the method is capable of detecting an unexpected event/anomaly when it takes place, which allows that the SDN can be reconfigured in real-time to avoid traffic congestion.

In a first possible implementation form of the method according to the second aspect, the method further comprises initiating a reconfiguration of the SDN by generating a new model or modifying an existing model and forecasting the data traffic based on the new/modified model.

Hence, the method allows reacting to unexpected events/anomalies in real-time by detecting that an unexpected event/anomaly takes place and adapting the prediction based on a new/modified model that fits the unexpected event/anomaly. In a second possible implementation form of the method according to the second aspect, the reconfiguration of the SDN comprises a reconfiguration of one or more switches of the SDN by implementing new forwarding rules.

Accordingly, traffic congestion can be avoided or reduced, even in cases of unexpected events/ anomalies. In a third possible implementation form of the method according to the second aspect, the method further comprises storing information on the one or more upcoming events, wherein the information comprises at least one of a starting date, an end date, an estimated traffic pattern comprising a traffic volume and a traffic shape over a time window between the starting and the end date, and an event category. Thus, the method allows predicting the shape of the upcoming data traffic. In a fourth possible implementation form of the method according to the second aspect, the method further comprises mining the information from the net by analyzing at least one of social media sites and/or blogs.

Hence, the method allows reacting in real-time to information becoming available on social media sites and/or blogs.

In a fifth possible implementation form of the method according to the second aspect, the model characterizes the estimated temporal relationship between the event and data traffic to be handled within the network by including parameters indicating a time instant relative to a course of the event at which a data traffic peak is to be expected. Accordingly, the method allows coping with data traffic peaks.

In a sixth possible implementation form of the method according to the second aspect, the model indicates data rates to be handled by SDN links at the time instant at which the data traffic peak is to be expected.

According to a third aspect of the present invention, there is provided a computer-readable medium, storing computer-readable instructions which, if carried-out by a processor, cause the processor to implement the method of any one of the second aspect or the implementation forms of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates a system for managing data traffic in an SDN, according to an example.

Fig. 2 schematically illustrates an exemplary dictionary of traffic shapes for two event categories. Fig. 3 shows a flow-chart of a procedure for managing data traffic in the SDN, according to an example.

Fig. 4 illustrates an exemplary prediction/error detection process which is based on different models that are used in parallel. Fig. 5 illustrates a process for detecting whether a traffic shape has already been recorded by the system.

DETAILED DESCRIPTION

Fig. 1 illustrates an exemplary system 10 for managing data traffic in an SDN. The system 10 comprises a database 12 which stores information about upcoming (real-life) events and data traffic measurements from network switches of the SDN. The information about upcoming events may be collected in various ways, such as by a human operator that inserts contextual information in the database 12 (e.g., type of the event, starting time, duration, etc.), or by automatically extracting (mining) contextual information from the internet, (e.g., by analyzing a micro blog, social media, Twitter, Facebook, etc.). For example, the contextual information may contain information about the category of an event, a starting time/hour of the event, an approximate duration of the event, etc.

The system 10 further comprises an SDN controller 14 that may transmit forecasting parameters to a prediction unit 16. The forecasting parameters may comprise, for example, a forecasting horizon (time span), a forecasting model/algorithm, and other parameters related to the prediction algorithm. The prediction unit 16 may operate in different modes. For example, in one mode, there may be no event expected within the prediction horizon and a normal forecasting model may be trained/used. In another mode, an event may be expected to take place within the prediction horizon such that the event needs to be taken into consideration.

The system 10 further comprises a knowledge unit 18 that may transform the contextual information (which may be passed from the database 12 to the knowledge unit 18 before an expected event takes place) to a specific model that can, for example, be used for time series prediction. In particular, a general abstraction for the representation of events may be performed in the knowledge unit 18, where each event may be represented by a parametric model comprising values for event parameters such as "duration/time of spikes", "amplitude" (t, A_t), etc. A possible implementation of a parametric model may be based on a dictionary of event- induced traffic shapes. For example, Fig. 2 shows different traffic shapes expressed by (t, A_t) for different event categories.

In general, events belonging to the same category or similar categories (e.g., concerts, sport events, trade fairs, etc.) are expected to cause a similar traffic shape in terms of the corresponding parametric model, whereas events belonging to different categories are expected to cause significantly different data traffic. To take this into account, different traffic shapes modeled by (t, A_t) may be given for different event categories. The database 12 may store the dictionary of such traffic shapes which may be passed to the prediction unit 16 when a corresponding event takes place.

For example, when an event that belongs to the category "Event A" is expected to take place, then the knowledge unit 18 may search for the relevant entry in the traffic shape dictionary. The knowledge unit 18 may then send an aggregate of the entries that belong to the event to the prediction unit 16 or may identify an entry which is closest (with respect to the contextual information) to the event and transmit the "duration/time of spikes" and "amplitude" information for this event. The duration of the event, as well as the traffic load during the time steps in which the event will be active may thus be calculated based on parameters derived from previous events, assuming that upcoming events will cause similar data traffic as past events of the same category.

When the knowledge unit 18 passes the event-related information to the prediction unit 16, the prediction unit 16 may use this information to predict the data traffic. For example, the ^.vanilla prediction . _\ ( \ prediction may be calculated by x_n+i = a * x_n+i + (1— a) * gi (y₀, ... , y_M_iJ, , _^vanilla prediction , , . , , . .. . . . , where the term x_n+i corresponds to a predicted value at time step n+i given by a

"conventional" time series prediction algorithm, e.g., ARIMA, Neural Networks, etc. The term x_n+i stands for the final prediction which includes information about the event. The shape chosen from the dictionary of shapes in the knowledge unit 18 determines the parameters Ύο_> ■■■ _< ΎΜ-Ι · Moreover, the function g_t may be chosen a-priori, or may be learned with respect to past observations and the context of the event. Finally, a £ [0,1] may be a user-defined parameter, which determines to what extend event-related information will be taken into account. If a = 0 then only the event-related information is taken into account, whereas if a = 1, only the vanilla prediction is taken into account.

The prediction unit 16 may send the predicted data traffic values to the SDN controller 14. The SDN controller 14 may indicate the prediction horizon, i.e., the time span to be covered by the prediction, and/or other parameters, e.g., constraints on the complexity of the models, as well as model specific parameters (order of the model, step-sizes, etc.), to the prediction unit 16.

In addition, the system 10 may have to deal with situations, in which an upcoming event has not been stored in the database 12, but needs to be identified and handled while it takes place. Such situations may involve the live unit 20. For instance, if a prediction error, i.e., the absolute value of the difference between the forecasted data traffic and the actual data traffic for one or more links as reported by the reporting unit 22 is larger than a predefined threshold, it may be checked, whether an event that currently takes place corresponds to an event category that is known to the system 10. To that direction, the resemblance of an event that takes place to known event categories may be measured and if a matching event category is identified, the database 12 may be updated by storing the event and assigning the respective event category to the event. Otherwise, another (novel) event category may be stored and assigned to the event that is taking place.

Fig. 3 shows a flow-chart of a procedure for managing data traffic in an SDN according to an example. The procedure is composed of eight steps SI to S8. At step SI, an application requests the prediction unit 16 to predict the data traffic for the next time steps. The time granularity, the employed algorithms that will be used for the time series prediction, as well as the horizon may be given as input. At step S2, the SDN controller 14 may send requests to the network switches and the knowledge unit 18 to initiate an event-aware traffic prediction counter collection. For example, the SDN controller 14 may initiate a flow counter using the OpenFlow protocol.

At step S3, the database 12 may collect new traffic measurements from the network switches and contextual information about upcoming events. At step S4, the prediction unit 16 may apply a learned model or learn a new one with respect to the past data and predict the data traffic for the required time horizon. Moreover, if there is an upcoming event, which is stored in the database 12, it may be taken into consideration as well.

At step S5, the SDN controller 14 may send new forwarding plane (TCAM) routing rules to the switches or initiate a command for capacity expansion/reduction in accordance with the predicted values. For the prediction of the next point/points on the timeline, an ensemble of predictors may be used. I.e., different models may be trained/used in parallel to estimate the predicted future data traffic values. Moreover, weights may be associated to the different models and after a number of iterations, only those models that lead to low error may be assigned large weights, whereas the remaining models will have assigned weights close to zero. At step S6, the live unit 20 may be activated, if the prediction error is larger than a specific threshold for more than a predefined number of steps. This may be the case either because the system 10 is unaware of an upcoming event (i.e., the upcoming event is unexpected) or because an upcoming event has been assigned to the wrong category (or the correct event category does not yet exist). At step S7, information about novel events may be stored in the database 12 and passed to the knowledge unit 18 for processing. At step S8, the knowledge unit 18 may pass the event-related parameters to be taken into account (in the prediction) to the prediction unit 16.

In another example, the transition from S4 to S5 may happen regardless of whether the question in the diamond box is answered with "yes" or "no". That is, if the error is smaller than the threshold, the live unit 20 may not be activated and the normal operation may take place, i.e., the prediction points are exploited by the network management (e.g., for capacity expansion) and the procedure returns to S3 to process new measurements on the data traffic. But even in case of a "yes," there may also be a transition from S4 to S5, which occurs in parallel to the transition from S4 to S6. When a transition from S6 to S4 occurs, a novel event may be collected in the database 12. Otherwise, the live unit 20 may be used to improve the performance. The scope of the live unit 20 is thus threefold. The first goal is to detect when an event that wasn't reported (before its actual start) takes place. The second goal is to allow predicting (as accurately as possible) the traffic caused by the event despite the fact that it hasn't been reported before. The third goal is to evaluate the novelty of the event that took place, so as to insert it in the dictionary of recorded/known traffic shapes, if needed. Fig. 4 illustrates an exemplary prediction process which is based on different models that may be trained/used in parallel. I.e., different traffic shapes may be used in parallel for the data traffic prediction. In particular, several different predictions may be produced based on different traffic shapes, where each traffic shape defines a different set of parameters y₀, ... , y_M- - A weight, which may take values between 0 and 1 may be associated to each different traffic shape and as new measurements on the data traffic are reported by the reporting unit 22, the error may be computed and lower weights may be given to those traffic shapes that result in high prediction errors. A specific choice of weights that leads to this behavior is _t(i) = e^~/^3et( / ∑yLi ^{e ~}P^6t^ , where e_t (i) is the error using event i and β is a user-defined parameter. The final prediction may be given by: x_t =∑™ ₁ a_t(i)x_t(i).

The computed weights may also be used to detect whether an event is novel or not, as is illustrated in Fig. 5. In particular, if there is a weight that is close to 1, this implies that the current event is similar to an already known event. On the contrary, if all the weights are far from 1, this implies that the current event hasn't been recorded before. Hence, a new database event entry may be generated by the knowledge unit 18. Finally, if a new event is detected, information about the event may be collected, e.g., via crowdsourcing.

Hence, the presented system/procedure may use contextual information to recognize future events, translate the contextual information to a proper model to be used for data traffic prediction, and identify unexpected events in real-time/conclude whether an unexpected event is novel or not.

Claims

1. A system for managing data traffic in a software defined network, SDN, the system comprising: a knowledge unit, the knowledge unit being configured to maintain a plurality of models, a model characterizing an estimated temporal relationship between an event and data traffic to be handled within a network comprising the SDN; a prediction unit, the prediction unit being configured to forecast data traffic to be handled by the SDN within a time span based on: mapping one or more upcoming aperiodic events to one or more of the models, if information on an upcoming aperiodic event is available; or data traffic reported by the SDN during a corresponding time span; a live unit, the live unit being configured to compare the forecast data traffic to be handled by the SDN within the time span with data traffic reported by the SDN during the time span, wherein, if differences between the forecast data traffic and the reported data traffic are assessed as substantial by the live unit, the live unit is configured to: initiate a reconfiguration of the SDN; and/or cause the knowledge unit to generate a new model or modify an existing model, the new/modified model mapping one or more current events to the reported data traffic.

2. The system of claim 1, wherein the live unit is configured to initiate a reconfiguration of the SDN by causing the knowledge unit to generate the new model or modify the existing model and providing the new/modified model to the prediction unit to forecast the data traffic based on the new/modified model.

3. The system of claim 1 or 2, wherein the reconfiguration of the SDN comprises a reconfiguration of one or more switches of the SDN by implementing new forwarding rules.

4. The system of any one of claims 1 to 3, further comprising: a database, the database storing information on the one or more upcoming events and/or one or more current events, wherein the information comprises at least one of a starting date, an end date, an estimated traffic pattern comprising a traffic volume and a traffic shape over a time window between the starting and the end date, and an event category.

5. The system of any one of claims 1 to 4, wherein the system is configured to mine the information from the net.

6. The system of any one of claims 1 to 5, wherein the model characterizes the estimated temporal relationship between the event and data traffic to be handled within the network by including parameters indicating a time instant relative to a course of the event at which a data traffic peak is to be expected.

7. The system of claim 6, wherein the model indicates data rates to be handled by SDN links at the time instant at which the data traffic peak is to be expected.

8. A method for managing data traffic in a software defined network, SDN, the method comprising: maintaining a plurality of models in a knowledge database, a model characterizing an estimated temporal relationship between an event and data traffic to be handled within a network comprising the SDN; forecasting data traffic to be handled by the SDN within a time span, by mapping one or more upcoming aperiodic events to one or more of the models, if information on an upcoming aperiodic event is available; comparing the forecast data traffic to be handled by the SDN within the time span with data traffic reported by the SDN during the time span, and, depending on a result of the comparison, initiating a reconfiguration of the SDN.

9. The method of claim 8, further comprising: initiating a reconfiguration of the SDN by generating a new model or modifying an existing model and forecasting the data traffic based on the new/modified model.

10. The method of claim 8 or 9, wherein the reconfiguration of the SDN comprises a reconfiguration of one or more switches of the SDN by implementing new forwarding rules.

1 1. The method of any one of claims 8 to 10, further comprising: storing information on the one or more upcoming events, wherein the information comprises at least one of a starting date, an end date, an estimated traffic pattern comprising a traffic volume and a traffic shape over a time window between the starting and the end date, and an event category.

12. The method of any one of claims 8 to 1 1, further comprising; mining the information from the net by analyzing at least one of social media sites and/or blogs.

13. The method of any one of claims 8 to 12, wherein the model characterizes the estimated temporal relationship between the event and data traffic to be handled within the network by including parameters indicating a time instant relative to a course of the event at which a data traffic peak is to be expected.

14. The method of claim 13, wherein the model indicates data rates to be handled by SDN links at the time instant at which the data traffic peak is to be expected.

15. A computer-readable medium, storing computer-readable instructions which, if carried- out by a processor, cause the processor to implement the method of any one of claims 8 to 14.