Apparatus and method for load balancing

Abstract

A device and a method, relating to load balancing in a network, in particular to a centralized solution for load balancing with built-in protection. To this end, the device and the method comprise a controller (300) configured to obtain traffic information (301) of one or more tunnels in the network, wherein the traffic information (301) of each tunnel is indicative of a type of protection against failure of the tunnel, and to provide configuration information (302) to each network node (310) being a head-end node of a determined tunnel having a certain type of protection based on the traffic information (301) obtained for the determined tunnel, wherein the configuration information (302) comprises a bandwidth threshold and a load balancing configuration of the determined tunnel. Furthermore, the disclosure proposes a network node (310) configured to receive configuration information (302) from the controller (300) upon determining that the traffic of the tunnel exceeds the bandwidth threshold, and to send a notification to the controller (300).

Description

TECHNICAL FIELD

[0001] The present invention relates to communication networks, and more particularly to load balancing of traffic in communication networks. To improve network utilization and minimize traffic loss in case of failure, the present invention proposes a global configuration of load balancing with protection. The invention particularly relates to load balancing traffic over multiple paths of a tunnel. BACKGROUND

[0002] Load balancing plays a crucial role in improving network utilization. The main principle of load balancing is to split traffic over multiple paths in order to better utilize network capacity.

[0003] Today, for example, a software-defined networking (SDN) controller or a path computation element (PCE) can integrate traffic engineering methods to continuously optimize routing and load balancing. These centralized control plane entities take advantage of the global view of the network to decide whether it is necessary to split traffic flows and to decide the most efficient splitting method according to some statistics of network load and traffic.

[0004] Generally, load balancing (or splitting) is implemented inside network elements such as switches or routers, using in particular two techniques: (1) hash-based splitting, where a hash is computed in important fields of the packet header and used to select an egress path; (2) weighted cost multi-pathing (WCMP), where load balancing weights are used to ensure that the number of flows over each egress path satisfies a certain proportion. In both cases, once a decision is made for a flow, all packets from the flow can follow the same decision and thus the same path.

[0005] Traditional protection mechanisms (without load balancing) consider that a primary path is protected by one or more backup paths. A typical example is the so-called 1+1 protection, where traffic is fully duplicated over two paths. This solution does not load balance traffic before and after failure. This can lead to high bandwidth utilization of some links or to the impossibility to protect traffic due to lack of resources.

[0006] Traditional protected load balancing methods consider one backup path per primary sub-path involved in a tunnel load balancing. In terms of bandwidth utilization, this mechanism is equivalent to 1+1 protection, which requires bandwidth reservation through multi-protocol label switching. SUMMARY

[0007] In view of the above-mentioned drawbacks, it is an object of embodiments of the present application to introduce a centralized technical solution that protects traffic against a set of possible failures when the traffic is load balanced over multiple paths of a tunnel. In particular, it is an object to globally configure secure load balancing by predicting all possible load shifts that can occur when at least one path fails. It is an object to more efficiently utilize bandwidth. It is another object to minimize traffic loss when a failure occurs, even to achieve zero traffic loss.

[0008] One or more of the above-mentioned objects are achieved by the embodiments provided in the independent claims. Advantageous implementations of the embodiments are further defined in the dependent claims.

[0009] A first aspect of the present application provides a controller for protected load balancing in a network, wherein the network comprises the controller and a plurality of network nodes, the controller being configured to: obtain traffic information for one or more tunnels in the network, wherein the traffic information for each tunnel indicates a type of protection of the tunnel against one or more failures; provide, to each network node that is a head-end node of a determined tunnel having a certain type of protection, configuration information based on the traffic information obtained for the determined tunnel, wherein the configuration information comprises a bandwidth threshold and a load balancing configuration for the determined tunnel, the bandwidth threshold being configured to instruct the network node to send a notification to the controller when traffic through the determined tunnel exceeds the bandwidth threshold (i.e. when the tunnel is no longer protected), the load balancing configuration being configured to indicate to the network node how to split the traffic through the determined tunnel over multiple paths of the determined tunnel in case of a failure.

[0010] The controller can be an SDN controller. The network nodes can be routers or switches. A tunnel is a channel between a source node (head-end network node) and a destination node (tail-end network node). In particular, a tunnel is a collection of flows from the same source node to the same destination node that are grouped together because they belong to the same application or tenant, or the same class of service.

[0011] Hence, one embodiment of the present application enables load balancing with built-in protection. In particular, the controller of the first aspect can "securely" balance the multiple paths of a tunnel, wherein "securely" means taking into account a set of possible failures that are identified. It is noted that a failure can be caused by at least one failed network component (e.g. a network node or a link between two network nodes) that is part of a path through the tunnel.

[0012] An initial load balancing configuration can be set for the multiple paths of the tunnel (e.g. by a controller), wherein the initial load balancing configuration can define how traffic flows are split over the paths of the tunnel without considering any failure. The general idea of the present invention is that the controller can also configure a "safe" split ratio of the traffic over the multiple paths of the tunnel by the load balancing configuration, wherein the load balancing configuration provided by the controller takes into account failures. That is, the controller can set a "safe" split ratio that helps other paths to carry the traffic over the tunnel without loss of traffic in case of a failure of a path of the tunnel.

[0013] For example, the split ratio over three paths of a tunnel can determine how much (e.g. in percentage) of the traffic is carried by each path. This can be achieved by the load balancing configuration information provided by the controller to the head-end node of the tunnel (i.e. source node of the tunnel). Furthermore, the indication that the head-end node sends the notification provides a further protection, because when the traffic over the tunnel exceeds the bandwidth threshold, a notification will be sent to the controller, and thus the tunnel is no longer protected. The controller can be able to react to this situation, e.g. by applying a greater bandwidth to the tunnel, or by reconfiguring the traffic split.

[0014] In an implementation form of the first aspect, the traffic information of the one or more tunnels further comprises quality of service, QoS, requirements, and / or comprises a traffic matrix including bandwidth estimates of the one or more tunnels.

[0015] The controller can receive input requirements related to traffic from an end user. In particular, the controller can receive traffic information per tunnel, e.g. different traffic information per tunnel. For example, for each tunnel, the controller can specify parameters in the traffic information related to one or more QoS requirements, e.g. end-to-end delay, maximum loss, including or excluding nodes / links of the traffic paths of the tunnel, etc. Furthermore, information of source and destination nodes of the tunnel can be included in the traffic information. The traffic matrix can carry information of a set of tunnels, in particular bandwidth per tunnel.

[0016] In an implementation form of the first aspect, the traffic information of the one or more tunnels further indicates a set of shared risk link groups, SRLGs, wherein each SRLG comprises a plurality of links of the one or more tunnels.

[0017] Failures are typically identified by SRLGs. An SRLG identifies a set of links that share a common resource, which can be a fiber or the like. Note that the term "link" as discussed herein refers to a direct link between two network nodes. Note that a path or routing path from a source node to a destination node can pass through multiple network nodes and can include multiple links. If the common resource fails, all links in the set will be affected. Thus, these links have the same risk of failure. That is, each SRLG includes multiple links in one or more tunnels that can fail together.

[0018] In an implementation form of the first aspect, the controller is further configured to obtain network information, wherein the network information comprises a topology of the network and / or characteristics of one or more links of the one or more tunnels; and determine the configuration information based on the obtained traffic information and the obtained network information.

[0019] The controller can also be aware of the network topology and / or the link characteristics (e.g. capacity, background traffic, packet loss, latency, etc.). Based on all these inputs, the controller can periodically adjust the load balancing of one or more tunnels globally.

[0020] In an implementation form of the first aspect, the determining the load balancing configuration for a tunnel is further configured to indicate the multiple paths for the tunnel and a split ratio for each path of the multiple paths; and the determining the load balancing configuration for a tunnel is further configured to indicate to the network nodes how to split the traffic through the tunnel among the multiple paths when the failure is a failure of one SRLG of a set of SRLGs intersecting one or more paths of the tunnel.

[0021] Note that when at least one link that is part of at least one path through the tunnel fails, the at least one path will be affected by this failure. To ensure minimal traffic loss, the load balancing can be implemented at the head-end node of a tunnel by sending the load balancing configuration to the head-end node by the controller. In particular, the load balancing configuration can indicate a set of routing paths through the tunnel associated with the head-end node with associated split ratios among the paths, wherein the split ratios are determined taking into account the failure.

[0022] In an implementation form of the first aspect, the controller is further configured to calculate the split ratio for each path using the obtained traffic information such that the load of a path affected by the failure can be transferred to one or more other paths that are not affected.

[0023] Thus, the load of the affected path, i.e. the traffic carried through this path, can be buffered (absorbed) by other paths. A specific algorithm can be used to calculate the split ratio of a set of tunnels. It is to be noted that different algorithms can be chosen, but the purpose of the calculation is that traffic can still be routed after a failure to avoid traffic loss. If bandwidth can be reserved on sub-paths, then zero loss of traffic can be ensured at SRLG failure.

[0024] In an implementation form of the first aspect, the configuration information further comprises bandwidth reservation information for the one or more paths of the determined tunnel.

[0025] Optionally, if the network application multi-protocol label switching (MPLS) technology, then, for example, at a failure, the bandwidth reservation information reserves how much available bandwidth of the one or more paths to the network node. MPLS is a routing technique used in telecommunication networks, in which data from one node is directed to the next node based on short path labels rather than long network addresses. In particular, when MPLS is used, bandwidth can be reserved for each sub-path to avoid traffic loss at failure.

[0026] In an implementation form of the first aspect, the bandwidth reservation information comprises bandwidth information shared by the one or more paths and / or bandwidth information for one path and not shared by other paths.

[0027] Possibly, the protection on a path, i.e. the reserved bandwidth, can be shared with other paths.

[0028] In an implementation form of the first aspect, the controller is further configured to receive one or more notifications from one or more of the network nodes, wherein each notification is indicative of traffic through the one or more tunnels exceeding the bandwidth threshold or of a failure in the respective network node, and to adjust the configuration information based on the received one or more notifications.

[0029] Optionally, the network nodes, in particular the source nodes (head-end nodes) of the tunnels, monitor the protection status of the tunnels associated therewith, e.g. the tunnel throughput and / or bandwidth utilization. Accordingly, the network nodes can also notify the controller in order to enable a global re-optimization of the load balancing.

[0030] In an implementation form of the first aspect, each notification comprises one or more of the following: the failure, abnormal traffic information, tunnel bandwidth information, current load balancing configuration and local bandwidth threshold of the respective network node.

[0031] Optionally, the notification sent by the network nodes can be an alarm message.

[0032] In an implementation form of the first aspect, the controller is further configured to determine, based on the received one or more notifications, a protection status of the one or more tunnels, wherein the protection status of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel, and to provide the protection status of the one or more tunnels.

[0033] For example, the controller can output the protection status (e.g. protected, unprotected) of all tunnels to an end user.

[0034] In an implementation form of the first aspect, the controller is further configured to periodically adjust the configuration information based on the received one or more notifications and / or the obtained traffic information.

[0035] Based on all these inputs, the controller can periodically and globally adjust the configuration information.

[0036] A second aspect of the present application provides a network node for protected load balancing in a network, wherein the network comprises a controller and a plurality of network nodes, the network node being a head-end node of a tunnel in the network, the network node being configured to receive configuration information from the controller, wherein the configuration information comprises a bandwidth threshold and a load balancing configuration of the tunnel, the bandwidth threshold being configured to instruct the network node to send a notification to the controller when traffic through the tunnel exceeds the bandwidth threshold, the load balancing configuration being configured to instruct the network node how to split the traffic through the tunnel among a plurality of paths of the tunnel in case of a failure, and to send the notification to the controller upon determining that the traffic through the tunnel exceeds the bandwidth threshold.

[0037] Accordingly, one embodiment of the present application proposes a network node for monitoring the local protection status of its tunnel as head-end node. A head-end node is a node that is the source of the tunnel, i.e. the node where the tunnel starts. In particular, the network node can monitor the tunnel protection status according to a critical bandwidth level, i.e. according to the bandwidth threshold obtained from the controller. If the tunnel is no longer protected, the network node sends the notification. Moreover, according to the instructions of the tunnel (load balancing configuration), the network node can apply the above-mentioned "safe" split ratio to its tunnel.

[0038] In an implementation form of the second aspect, the network node is further configured to send the notification to the controller upon detecting a failure in the network node.

[0039] Optionally, the head-end node of the tunnel can also send an alarm message to the controller upon failure.

[0040] In an implementation form of the second aspect, the load balancing configuration of the tunnel is configured to indicate the multiple paths of the tunnel and a split ratio of each path of the multiple paths, wherein the load balancing configuration of the tunnel is configured to indicate how the network node splits the traffic through the tunnel among the multiple paths when the failure is a failure of an SLRG intersecting one or more paths of the tunnel, the SLRG comprising multiple links of the one or more tunnels.

[0041] Failures are usually identified by SRLGs. Links belonging to the same SRLG have the same failure risk. It is noted that if a path comprises one SRLG link, the path also has the same failure risk.

[0042] In an implementation form of the second aspect, the network node is configured to split the traffic through the tunnel among the multiple paths according to the split ratio comprised in the load balancing configuration of the tunnel.

[0043] Thus, the head-end node of the tunnel can apply a "safe" split ratio to the paths of its associated tunnel.

[0044] In an implementation form of the second aspect, the configuration information further comprises bandwidth reservation information of one or more paths of the tunnel.

[0045] Optionally, if the network applies MPLS technology, the network node can also receive bandwidth reservation information.

[0046] In an implementation form of the second aspect, the bandwidth reservation information comprises bandwidth information shared by the one or more paths and / or bandwidth information for one path and not shared by other paths.

[0047] In an implementation form of the second aspect, the notification comprises one or more of the following: the failure, abnormal traffic information, tunnel bandwidth information, current load balancing configuration and local bandwidth threshold of the respective network node.

[0048] A third aspect of the present application provides a user equipment for supporting protected load balancing in a network, wherein the network comprises a controller and a plurality of network nodes, the user equipment configured to: provide traffic information of one or more tunnels in the network to the controller, wherein the traffic information of each tunnel indicates a protection type of the tunnel against one or more failures; obtain a protection status of the one or more tunnels from the controller, wherein the protection status of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel.

[0049] Therefore, embodiments of the present application propose a user equipment for providing input to the controller about traffic associated with a set of tunnels and obtaining information about the protection status of all tunnels from the controller. With the traffic information of the one or more tunnels, the user equipment can request the protection type of each tunnel. The user equipment can delay sending the traffic until receiving an acknowledgement that the protection status of the one or more tunnels matches the provided / requested protection type.

[0050] In an implementation form of the third aspect, the traffic information of the one or more tunnels further comprises quality of service (QoS) requirements and / or a traffic matrix comprising bandwidth estimations of the one or more tunnels.

[0051] Therefore, the user equipment can indicate what QoS each tunnel needs and what bandwidth it estimates each tunnel needs.

[0052] In an implementation form of the third aspect, the traffic information of the one or more tunnels is further configured to indicate a set of SRLGs, each SRLG comprising a plurality of links of the one or more tunnels.

[0053] In an implementation form of the third aspect, the one or more failures comprise a failure of one SRLG in a set of SRLGs intersecting one or more paths of a tunnel.

[0054] A fourth aspect of the present application provides a method for protected load balancing in a network, wherein the network comprises a controller and a plurality of network nodes, the method comprising the following steps performed by the controller: obtaining traffic information of one or more tunnels in the network, wherein the traffic information of each tunnel indicates a protection type of the tunnel against one or more failures; providing configuration information to each network node that is a head-end node of a determined tunnel having a certain protection type according to the traffic information obtained for the determined tunnel, wherein the configuration information comprises a bandwidth threshold and a load balancing configuration of the determined tunnel, the bandwidth threshold is used to instruct the network node to send a notification to the controller when traffic through the determined tunnel exceeds the bandwidth threshold, and the load balancing configuration is used to indicate to the network node how to split the traffic through the determined tunnel among a plurality of paths of the determined tunnel when a failure occurs.

[0055] Implementations of the method of the fourth aspect can correspond to the implementations of the controller of the first aspect described above. The method of the fourth aspect and its implementations achieve the same advantages and effects as the entity of the first aspect and its corresponding implementations.

[0056] A fifth aspect of the present application provides a method for protected load balancing in a network, wherein the network comprises a controller and a plurality of network nodes, wherein the method comprises the following steps performed by a network node that is a head-end node of a tunnel in the network: receiving configuration information from the controller, wherein the configuration information comprises a bandwidth threshold and a load balancing configuration of the tunnel, the bandwidth threshold is used to instruct the network node to send a notification to the controller when traffic through the tunnel exceeds the bandwidth threshold, and the load balancing configuration is used to indicate to the network node how to split the traffic through the tunnel among a plurality of paths of the tunnel when a failure occurs; sending the notification to the controller according to a determination that the traffic through the tunnel exceeds the bandwidth threshold.

[0057] Implementations of the method of the fifth aspect can correspond to the implementations of the network node of the second aspect described above. The method of the fifth aspect and its implementations achieve the same advantages and effects as the network node of the second aspect and its corresponding implementations.

[0058] The sixth aspect of the present application provides a method for protected load balancing in a network, wherein the network comprises a controller and a plurality of network nodes, wherein the method comprises the following steps performed by a user equipment for supporting protected load balancing: providing traffic information of one or more tunnels in the network to the controller, wherein the traffic information of each tunnel indicates a protection type of the tunnel against one or more failures; obtaining a protection status of the one or more tunnels from the controller, wherein the protection status of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel.

[0059] The implementation of the method of the sixth aspect can correspond to the implementation of the user equipment of the third aspect described above. The method of the sixth aspect and its implementation achieves the same advantages and effects as the user equipment of the third aspect and its corresponding implementation.

[0060] The seventh aspect of the present application provides a computer product comprising a program code, wherein the program code is configured to implement the method according to the fourth aspect or any implementation of the fourth aspect, the fifth aspect or any implementation of the fifth aspect, or the sixth aspect or any implementation of the sixth aspect when executed on a processor.

[0061] It should be noted that all the devices, elements, units and modules described in the present application can be implemented in software or hardware elements or any combination thereof. The steps performed by the various entities described in the present application and the functions described by the various entities are intended to mean that the respective entities perform the respective steps and functions. Even if specific functions or steps to be performed by external entities are not reflected in the description of specific detailed elements of the entity performing the specific steps or functions in the following description of specific embodiments, it should be clear to the skilled person that these methods and functions can be implemented in corresponding software or hardware elements, or in any combination of such elements. BRIEF DESCRIPTION OF DRAWINGS

[0062] The above aspects of the present application and the implementation thereof will be described in more detail in the following description of specific embodiments in conjunction with the attached drawings, in which:

[0063] Figure 1 A network and switch architecture using hash-based load balancing is shown;

[0064] Figure 2 Load transfer after a failure is shown;

[0065] Figure 3 A controller provided by an embodiment of the present application is shown;

[0066] Figure 4Initial load balancing and protected load balancing provided by one embodiment of the present application is shown;

[0067] Figure 5 Initial load balancing and protected load balancing provided by one embodiment of the present application is shown;

[0068] Figure 6 A network node provided by one embodiment of the present application is shown;

[0069] Figure 7 A protected load balancing architecture provided by one embodiment of the present application is shown;

[0070] Figure 8 A network node provided by one embodiment of the present application is shown;

[0071] Figure 9 User equipment provided by one embodiment of the present application is shown;

[0072] Figure 10 A method provided by one embodiment of the present application is shown;

[0073] Figure 11 A method provided by one embodiment of the present application is shown;

[0074] Figure 12 A method provided by one embodiment of the present application is shown. DETAILED DESCRIPTION

[0075] Exemplary embodiments of a controller, network node, user equipment, and corresponding methods for efficient transmission of data packets in a communication system are described in conjunction with the appended drawings. While the description provides detailed examples of what can be implemented, it should be noted that these details are intended to be exemplary and in no way limit the scope of application.

[0076] Furthermore, embodiments / examples can refer to other embodiments / examples. For example, any description including but not limited to terminology, elements, procedures, explanations, and / or technical advantages mentioned in one embodiment / example apply to other embodiments / examples.

[0077] In hash-based load balancing techniques, a distinction can be made between uniform load balancing or non-uniform load balancing. The first type is the more popular type, also known as Equal Cost Multi-Path (ECMP). The second type can better utilize network resources, but is more difficult to implement. The second type is also known as Unequal Cost Multi-Path (UCMP). In both cases, the implementation inside the switch can make use of Ternary Content Access Memory (TCAM) memory for efficient packet processing. The TCAM memory inside the switch can also be divided into two tables: a forwarding table and a group table, as shown in Figure 1 .

[0078] In particular, Figure 1 A network and switch architecture using hash-based load balancing is shown, the switches being controlled by a SDN or PCE controller. For each incoming packet, the switch looks up the corresponding match for the packet destination address in a forwarding table, which indicates whether the packet can be directly forwarded or whether it has to comply with a specific load balancing, i.e. a specific path can need to be chosen for the packet (e.g. the flow the packet belongs to can be routed through another path than another flow). In the latter case, the switch further looks up the corresponding entry of a group table associated with the operation of the load balancing (here the group with group ID 1). For example, as shown in Figure 1 , for a demand D1 (e.g. a demand can be a flow of traffic through a tunnel from a source node of the tunnel to a destination node of the tunnel), the switch finds in the forwarding table that the corresponding "Action" is "Apply Group 1". Accordingly, the switch also finds in the group table the group with "Group ID" 1. Then, the next hop for the packet is determined according to the output of a hash computed on one or more packet fields, in particular a hash computed on the header of the packet. The configuration of the entries in the group table, also called buckets, defines the load balancing for the specific flow of traffic, i.e. the load balancing that can be used for a specific flow of traffic. The SDN or PCE controller can indicate each switch with the appropriate TCAM configuration, given the global view of the network.

[0079] Figure 2An example of load transfer after failure is shown. Specifically, when the next hop associated with a certain flow fails, the associated bucket will be removed, the split ratio will be automatically adjusted, and the load will be automatically transferred to the remaining buckets. In this example, when the link associated with next hop 56.78.91.3 fails, the load will be transferred to the remaining next hops. Accordingly, the split ratio of the flows corresponding to the remaining next hops is modified from (1 / 4, 1 / 2) to (1 / 3, 2 / 3).

[0080] The present invention proposes a protection mechanism that can be implemented on top of UCMP. It safely adjusts and monitors load balancing to improve network utilization and protect traffic from a set of failures that have been identified. The purpose of the present invention is to globally configure safe load balancing (i.e. configure split ratios for all tunnels) by predicting all possible load transfers that can occur when a failure occurs.

[0081] Embodiments of the present invention consider load balancing with built-in protection, in particular without distinguishing between primary or backup paths. Compared to traditional protection mechanisms, bandwidth is more efficiently utilized; traffic loss is minimized when no bandwidth reservation is used; traffic loss is even zero when bandwidth reservation is used. In fact, when a failure occurs, packets inside the network can be lost. But after reconfiguring the split ratios, subsequent packets arriving at the load balancer (i.e. the entity performing load balancing) do not experience congestion when bandwidth has been reserved.

[0082] The present invention can be logically divided into two parts: the first part can be implemented by a controller, for example a protected load balancing module in the controller; the second part can be implemented in a device, i.e. a network node, to monitor protection and inform the centralized controller for global re-optimization.

[0083] Figure 3An embodiment of the application provides a controller 300 for protected load balancing in a network is shown. The controller 300 can include processing circuitry (not shown) to perform, implement, or initiate the various operations of the controller 300 described herein. The processing circuitry can include hardware and software. The hardware can include analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry can include components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors, etc. The controller 300 can also include storage circuitry to store one or more instructions that can be executed by the processor or processing circuitry, particularly under the control of software. For example, the storage circuitry can include a non-transitory storage medium storing executable software code that, when executed by the processor or processing circuitry, causes the various operations of the controller 300 to be performed. In one embodiment, the processing circuitry includes one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory can carry executable program code that, when executed by the one or more processors, causes the controller 300 to perform, implement, or initiate the operations or methods described herein.

[0084] In particular, the network can include the controller 300 and a plurality of network nodes 310. The controller 300 is configured to obtain traffic information 301 of one or more tunnels in the network. It is noted that a tunnel establishes a path between a source node and a destination node in the network. The network nodes 310 can be head-end nodes of the tunnels in the network. The data / packets transmitted in the tunnels can have different routing paths. In particular, the traffic information 301 of each tunnel indicates a protection type of the tunnel against one or more failures. For example, the protection type can include: no protection (the tunnel does not support failure protection), or protected load balancing against a specific failure (the tunnel supports a set of identified failure protections).

[0085] Further, the controller 300 is configured to provide configuration information 302 to each network node 310 being a head-end node of a determined tunnel, based on the traffic information 301 obtained for the determined tunnel having a certain protection type. It is noted that for each tunnel there is one source / head-end node and one destination / tail-end node. The head-end node can be the router that configures the traffic in the tunnel and the tail-end node can be the router where the tunnel terminates. If the controller 300 knows that the determined tunnel is or should be a protected tunnel, the controller 300 can provide the head-end node of the determined tunnel with the relevant configuration information 302. The configuration information 302 comprises at least a bandwidth threshold and a load balancing configuration for the determined tunnel. In particular, the bandwidth threshold indicates that the network node 310 sends a notification 311 to the controller 300 if the traffic through the determined tunnel exceeds the bandwidth threshold. Thus, the bandwidth threshold can also be referred to as a critical bandwidth level. If the traffic through the determined tunnel exceeds the bandwidth threshold, the tunnel is no longer protected. That is, the notification 311 can thus be an alarm message. The load balancing configuration indicates how the network node 310 splits the traffic through the determined tunnel among the multiple paths of the determined tunnel in case of a failure. The network node 300 can route the traffic through the tunnel on the multiple paths according to the split indicated by the load balancing configuration received from the controller 300 according to the split ratio indicated by the load balancing configuration.

[0086] Optionally, according to an embodiment of the present application, the traffic information 301 of the one or more tunnels further comprises QoS requirements and / or a traffic matrix comprising bandwidth estimates of the one or more tunnels. The traffic matrix can comprise information of peak bandwidth and / or average bandwidth of the one or more tunnels.

[0087] According to an embodiment of the present application, it is possible that the traffic information of the one or more tunnels further indicates a set of SRLGs. Each SRLG can comprise a plurality of links of the one or more tunnels.

[0088] Failures are typically identified by SRLGs. An SRLG identifies a set of links that share a common resource. If the common resource is not available, all links in the set of links will be affected. Thus, these links have the same failure risk and are considered to belong to the same SRLG. For example, in a network having 3 links A, B and C, all possible single-link failures can be considered by considering the SRLG set {{A}, {B}, {C}}, and all possible double-link failures can be considered by considering the SRLG set {{AB}, {AC}, {BC}}.

[0089] The present invention aims at safely load balancing to cover a given set of SRLG failures. The general idea of the present invention is to configure "safe" split ratios to avoid traffic loss in case of any possible SRLG failure. If sub-paths can reserve bandwidth, zero traffic loss can be guaranteed. Controller 300 can ensure that this protection is provided for at least a certain period of time and can react if needed.

[0090] Figure 4 An example of how traffic is split in a tunnel to better protect the equipment from failures is shown for an embodiment of the present invention. In particular, how to apply split ratios for a tunnel of example size 100Mb is shown. The tunnel is split over 3 paths to protect against all possible single chain failures. In this example, the number of SRLGs is equal to the number of links. For example, load balancing is initially (e.g. traditionally) allocated as 20%, 40%, 40% on the 3 paths (as shown on the left side). It can be calculated, for example by controller 300, how much bandwidth will be used in the worst case of this initial (traditional) load balancing. In this example, the worst case utilization of the three paths is calculated as 33.4Mb, 66.7Mb, 66.7Mb when considering all possible single chain failures. A max function (as shown on the right side) helps to take into account the worst case failure scenario for each path through the tunnel when calculating the required bandwidth, considering all possible SRLG failures outside the path. Controller 300 can then apply split ratios between the paths based on these calculations to better protect the equipment from these types of failures. It is noted that controller 300 can take into account the capacity of the links when calculating these "safe" split ratios. Alternatively, a protected load balancing module installed in controller 300 can perform the calculations. Figure 4 Figure 4

[0091] From this example, it can be deduced that the protection mechanism proposed by the present invention is more efficient than, for example, traditional 1+1 protection (where traffic is fully duplicated on two paths, i.e. twice the size of the tunnel) because the proposed protection mechanism consumes a total of 166.8Mb of bandwidth, whereas 1+1 protection would consume 200Mb of bandwidth.

[0092] Figure 5 Another example of how traffic is split in a tunnel is shown for an embodiment of the present invention. In particular, traffic is split in network node 310 according to an embodiment of the present invention. Network node 310 can get the split ratios from configuration information 301 provided by controller 300. In this example, the tunnel is of size 100Mb and is split into 4 paths to protect against all possible single chain failures. As for the previous example, the number of SRLGs is equal to the number of links. For example, load balancing is initially (e.g. traditionally) allocated as 25%, 25%, 25%, 25% on the 4 paths (as shown on the left side). It can be calculated, for example by controller 300, how much bandwidth will be used in the worst case of this initial (traditional) load balancing. In this example, the worst case utilization of the four paths is calculated as 25.0Mb, 50.0Mb, 50.0Mb, 50.0Mb when considering all possible single chain failures. A max function (as shown on the right side) helps to take into account the worst case failure scenario for each path through the tunnel when calculating the required bandwidth, considering all possible SRLG failures outside the path. Controller 300 can then apply split ratios between the paths based on these calculations to better protect the equipment from these types of failures. It is noted that controller 300 can take into account the capacity of the links when calculating these "safe" split ratios. Alternatively, a protected load balancing module installed in controller 300 can perform the calculations. Figure 4 ​​Similar to the discussion, the number of SRLGs is equal to the number of links. When the load balancing over the 4 paths is initially 20%, 30%, 30%, 20% (as shown on the left side) Figure 5 , for example, the controller 300 (as shown on the right side) Figure 5 may calculate the bandwidth required for the worst case failure scenario. Similar to the discussion in Figure 4 , the max function shown in Figure 5 helps to consider the worst case failure scenario for each path through the tunnel, among all possible SRLG failures outside the path, when calculating the required bandwidth. In this embodiment, it can be observed that the proposed protection mechanism consumes a total of 171.5 Mb bandwidth, instead of the 200 Mb bandwidth of 1+1 protection.

[0093] Furthermore, it is important to note that in the embodiments shown in Figure 4 and Figure 5 , the given bandwidth requirement of the protection on the tunnel is valid. That is, if the traffic exceeds the exemplary 100 Mb in the tunnel, the traffic can no longer be protected. To address this issue, the present invention proposes to use and monitor a “critical bandwidth level” for each tunnel. When the traffic within the tunnel is higher than the critical bandwidth level, or when there is not enough residual bandwidth in the network due to background traffic, the network node 310 (or the load balancer within the network node 310) can inform the controller 300 in order to reconfigure the load balancing.

[0094] In one embodiment of the present invention, the following algorithm can be used to calculate the split ratio for a set of tunnels in the controller 300.

[0095] Algorithm:

[0096] - Consider a set of disjoint paths P for each tunnel k k (not sharing a path from the same SLRG)

[0097] - Let min BW be the minimum percentage of the tunnel bandwidth allocated on the path (e.g., 1 / 16)

[0098] - For each tunnel k

[0099] o Assign min k to each path of P BW

[0100] o Although the split ratio can still be modified

[0101] ■ Evaluate the protection bandwidth w BW required to prevent SRLG failures when the utilization on the path p is increased by min pk

[0102] ■ For w with minimum value pk If there is enough remaining capacity, add min BW

[0103] If the sum of the split ratios allocated to tunnel k is less than 1, then

[0104] ■ Remove all split ratios associated with tunnel k

[0105] – Return the split ratios for each path and each tunnel.

[0106] – Alternatively, evaluate and return the bandwidth reservations for each path.

[0107] Figure 6 A network node 310 suitable for protected load balancing in a network is shown as provided by one embodiment of the present invention. The network node 310 can include processing circuitry (not shown) to perform, conduct or initiate the various operations of the network node 310 described herein. The processing circuitry can include hardware and software. The hardware can include analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry can include components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors, etc. The network node 310 can also include storage circuitry storing one or more instructions that can be executed by the processor or processing circuitry, particularly under control of software. For example, the storage circuitry can include a non-transitory storage medium storing executable software code that, when executed by the processor or processing circuitry, causes the various operations of the network node 310 to be performed. In one embodiment, the processing circuitry includes one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory can carry executable program code that, when executed by the one or more processors, causes the network node 310 to perform, conduct or initiate the operations or methods described herein.

[0108] In particular, the network can comprise a controller 300 and a plurality of network nodes 310. The network nodes 310 are head-end nodes of a tunnel in the network, wherein the network nodes 310 are configured to receive configuration information 302 from the controller 300. In particular, the configuration information 302 comprises a bandwidth threshold and a load balancing configuration for the tunnel. The bandwidth threshold indicates that the network nodes 310 are configured to send a notification 311 to the controller 300 if the traffic through the tunnel exceeds the bandwidth threshold. The bandwidth threshold can also be referred to as a critical bandwidth level. The load balancing configuration indicates to the network nodes 310 how to split the traffic through the tunnel among a plurality of paths of the tunnel in case of a failure.

[0109] Further, the network nodes 310 are configured to send a notification 311 to the controller 300 if it is determined that the traffic of the tunnel exceeds the bandwidth threshold. In this way, the network nodes 310 can inform the controller 300 that the tunnel is no longer protected and thus the load balancing can be reconfigured. Optionally, the network nodes 310 can also be configured to send a notification 311 to the controller if a failure is detected in the network nodes 310.

[0110] Figure 7 A system architecture provided by one embodiment of the present application is shown. The architecture comprises a controller 300 and network nodes 310. In particular, the controller 300 can be a controller as shown in Figure 3 The network nodes 310 can be network nodes as shown in Figure 6 .

[0111] As shown in Figure 7 , the controller 300 can comprise a protected load balancing configuration module. The protected load balancing configuration module can receive input related to a set of tunnels (e.g. from an end user). For each tunnel, a protection type (e.g. unprotected or protected load balancing) can be defined and a set of SRLG failures can be given. Other parameters can be specified, e.g. parameters related to QoS requirements such as end-to-end delay, loss, inclusion or exclusion of nodes / links, etc. The protected load balancing configuration module can also be aware of the network topology and link characteristics (e.g. capacity, background traffic, packet loss, delay, etc.). Based on all these inputs, the protected load balancing configuration module can periodically adjust the load balancing of the tunnels globally. It is noted that the load balancing can be implemented at the head-end of the tunnels, inter alia, by sending a set of routing paths with associated split ratios to the devices.

[0112] Optionally, according to one embodiment of the present application, the controller 300 can also be configured to obtain network information 303, wherein the network information 303 comprises a topology of the network and / or characteristics of one or more links of the one or more tunnels. Further, the controller 300 can be configured to determine the configuration information 302 based on the obtained traffic information 301 and the obtained network information 303.

[0113] In case of protected load balancing, i.e. the traffic information 301 indicates that one of the plurality of tunnels is protected from certain failures, critical bandwidth is communicated to the network node 310 so that the network node 310 can monitor the protection status. The network node 310 can be a switch or a router.

[0114] In particular, determining the load balancing configuration of the tunnel comprises determining a plurality of paths of the tunnel and indicating a split ratio for each path of the plurality of paths. Optionally, determining the load balancing configuration of the tunnel further comprises indicating to the network node 310 how to split traffic through the tunnel among the plurality of paths when a failure is a failure of one of a set of SLRGs intersecting one or more paths of the tunnel.

[0115] Correspondingly, the network node 310 can be configured to split traffic through the tunnel among the plurality of paths according to the split ratios comprised in the load balancing configuration of the tunnel. To this end, the network node 310 can comprise a load balancer.

[0116] Optionally, the controller 300 can be further configured to calculate the split ratios for each path using the acquired traffic information 301 so that the load of a path affected by a failure can be shifted onto one or more other paths not affected.

[0117] It is noted that different algorithms can be used to calculate the split ratios for a set of tunnels. It is noted that the purpose of the calculation is that after a failure, traffic can still be routed so that traffic loss is avoided.

[0118] Optionally, according to an embodiment of the present application, the configuration information 302 further comprises bandwidth reservation information for determining one or more paths of the tunnel. When using bandwidth reservations, e.g. using MPLS technology, zero traffic loss can be ensured when an SRLG failure occurs. Possibly, the bandwidth reservation information can comprise bandwidth information shared by one or more paths and / or bandwidth information for one path and not shared by other paths.

[0119] It is noted that MPLS is a routing technique in telecommunications networks that directs data from one node to the next based on short path labels rather than long network addresses, avoiding complex lookups in routing tables while speeding up traffic flow. Short path labels are used to identify virtual links (paths) between remote nodes rather than end points. MPLS can encapsulate packets of various network protocols, hence the “multi-protocol” reference. MPLS supports a range of access technologies. When MPLS is used, explicit bandwidth reservations can be enforced on each sub-path in order to have zero traffic loss in case of failure. When Segment Routing over IPv6 (SRv6) technology is used, bandwidth reservations cannot be implemented and the controller 300 can only direct traffic in a way that has minimal loss in case of failure.

[0120] Optionally, the controller 300 according to an embodiment of the present application can also be configured to receive one or more notifications 311 from one or more network nodes 310. In particular, each notification 311 can indicate that one or more tunnels are not protected because traffic through the respective network node 310 exceeds a bandwidth threshold or indicate a failure in the respective network node 310. Furthermore, the controller 300 can also be configured to adjust the configuration information 302 according to the received one or more notifications 311.

[0121] Possibly, each notification 311 comprises one or more of the following: a failure, abnormal traffic information, tunnel bandwidth information, a current load balancing configuration and a local bandwidth threshold of the respective network node according to an embodiment of the present application.

[0122] Furthermore, the controller 300 can also be configured to determine the protection status 304 of one or more tunnels according to the received one or more notifications 311 according to an embodiment of the present application. The protection status 304 of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel. Then, the controller 300 can also be configured to provide the protection status 304 of one or more tunnels (e.g. to an end user device).

[0123] According to all inputs, the controller 300 can also be configured to adjust the configuration information 302 according to the received one or more notifications and / or the acquired traffic information 301.

[0124] Figure 8 A network node 310 and a protection analysis module in the network node 310 provided by an embodiment of the present application are shown. The network node 310 can implement the protection analysis module, e.g. as Figure 8The network node 310 or the protection analysis module in the network node 310 can observe the real-time traffic and can trigger an alarm if the traffic exceeds the critical bandwidth level. It is noted that the traffic can thus be sampled. Furthermore, a timer can be added to avoid notifying the controller 300 several times in a row. Furthermore, the protection analysis module can also notify the controller 300 of a failure so that the controller 300 can react. The alarm message sent to the controller 300 can include information about the nature of the load balancing problem (e.g. failure, abnormal traffic), tunnel bandwidth information (e.g. average rate and peak rate), the current load balancing configuration (split ratio on each path) and the local critical bandwidth level (if updated / modified locally) in case of traffic exceeding the critical bandwidth level or in case of a failure. It is noted that the alarm message can be implemented on top of the PCE Communication Protocol (PCEP), as a Simple Network Management Protocol (SNMP) trap or using the Network Configuration Protocol (NetConf).

[0125] Optionally, the application also proposes a user device for providing the traffic information 301 to the controller 300 and obtaining the protection status 304 of the tunnels. At any time, the protected load balancing module in the controller 300 can output the protection status 304 of all tunnels (e.g. protected, unprotected) to the end user.

[0126] Figure 9 A user device 320 for supporting protected load balancing in a network is shown. Specifically, the network comprises a controller 300 and a plurality of network nodes 310. In a particular implementation, the controller 300 can be the controller shown, and one or more of the network nodes 310 can be the network node shown. Figure 3 Figure 6

[0127] The user device 320 is configured to provide traffic information 301 of one or more tunnels in the network to the controller 300, wherein the traffic information 301 of each tunnel indicates a protection type of the tunnel against one or more failures. Furthermore, the user device 320 is configured to obtain a protection status 304 of the one or more tunnels from the controller 300, wherein the protection status 304 of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel.

[0128] Figure 10 ​​A method 1000 provided by an embodiment of the present invention is illustrated, particularly for protected load balancing in a network. Specifically, the network includes a controller 300 and a plurality of network nodes 310. In a particular embodiment, method 1000 is performed by... Figure 3 The controller 300 shown executes the method. Method 1000 includes step 1001: acquiring traffic information 301 for one or more tunnels in the network, wherein the traffic information 301 for each tunnel represents the protection type of the tunnel against one or more faults. Method 1000 further includes step 1002: providing configuration information 302 to each network node 310 of the headend node of the determined tunnel based on the traffic information 301 acquired for the determined tunnel with a certain protection type, wherein the configuration information 302 includes a bandwidth threshold and a load balancing configuration for the determined tunnel, the bandwidth threshold being used to instruct the network node 310 to send a notification 311 to the controller 300 when traffic through the determined tunnel exceeds the bandwidth threshold, and the load balancing configuration being used to instruct the network node 310 how to distribute traffic through the determined tunnel across multiple paths in the event of a fault. Possibly, network node 310 is... Figure 6 or Figure 7 The network nodes shown.

[0129] Figure 11 A method 1100 provided by an embodiment of the present invention is illustrated, particularly for protected load balancing in a network. Specifically, the network includes a controller 300 and a plurality of network nodes 310. In a particular embodiment, method 1100 is performed by... Figure 6 The method is executed by network node 310. Specifically, network node 310 is the headend node of the tunnel in the network. Method 1100 includes step 1101: receiving configuration information 302 from controller 300, wherein the configuration information 302 includes a bandwidth threshold and a load balancing configuration for the tunnel, the bandwidth threshold being used to instruct network node 310 to send a notification 311 to controller 300 when traffic through the tunnel exceeds the bandwidth threshold, and the load balancing configuration being used to instruct network node 310 how to distribute traffic through the determined tunnel among multiple paths in the event of a failure. Method 1100 also includes step 1102: if the determined tunnel traffic exceeds the bandwidth threshold, sending a notification 311 to controller 300. Possibly, controller 300 is... Figure 3 or Figure 7 The controller shown.

[0130] Figure 12 A method 1200 provided by an embodiment of the present invention is illustrated, particularly for supporting protected load balancing in a network. Specifically, the network includes a controller 300 and a plurality of network nodes 310. In a particular embodiment, method 1200 is performed by... Figure 9The user equipment 320 shown performs. The method 1200 comprises a step 1201 of providing, to the controller 300, traffic information 301 of one or more tunnels in the network, wherein the traffic information 301 of each tunnel indicates a protection type of the tunnel against one or more failures. The method 1200 further comprises a step 1202 of obtaining, from the controller 300, a protection status 304 of the one or more tunnels, wherein the protection status 304 of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel. In particular, the controller 300 can be the controller shown in Figure 3 or Figure 7 The network node 310 can be the network node shown in Figure 6 or Figure 7 The network node 310 can be the network node shown in

[0131] The present application proposes an apparatus and a method for protected load balancing in IP networks. Embodiments of the present application provide a global configuration apparatus for a load balancer to prevent SRLG failures. In particular, the apparatus helps to adjust the split ratio of a set of tunnels or flow aggregates according to a given bandwidth requirement to prevent every possible SRLG failure. Embodiments of the present application further provide a detection of the protection level at the ingress device according to a critical bandwidth level. Various schemes are supported to minimize the traffic loss or guarantee zero traffic loss.

[0132] Embodiments of the present application propose a method to achieve zero or minimal traffic loss. In particular, the method helps to adjust the split ratio to fully protect the tunnels or flow aggregates in every possible SRLG failure. It guarantees that the load can be safely shifted to the remaining active paths. It is noted that embodiments of the present application can be implemented with and without bandwidth reservation.

[0133] In the case of SR, no bandwidth reservation can be done. The traffic loss cannot be guaranteed but is expected to be minimal. The split ratio will be adjusted periodically to follow the traffic variations, especially when the network applies the multi-protocol label switching technology.

[0134] In the case of MPLS, bandwidth reservation can be enforced on each sub-path.

[0135] The application has been described in relation to various embodiments and implementations as examples. However, other variations can be understood and effected by those skilled in the art in practising the claimed application, from a study of the drawings, the application and the independent claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality of elements or steps. A single element or other unit can fulfil the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0136] In addition, any of the methods according to embodiments of the application can be implemented in a computer program having a code module for making the processing module perform its method steps, when the computer program is run on the processing module. The computer program can be embodied on a computer readable medium. The computer readable medium basically includes any memory, such as a ROM (read-only memory), a PROM (programmable read-only memory), an EPROM (erasable PROM), a flash memory, an EEPROM (electrically erasable PROM), or a hard disk drive.

[0137] Furthermore, it is realized by the skilled person that embodiments of the controller 300, the network node 310 or the user equipment 320 comprise the necessary communication capabilities in the form of functions, modules, units, elements etc. for performing the technical solutions. Examples of other such modules, units, elements and functions are: processors, memories, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selection units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiving units, transmitting units, DSPs, TCMs, TCM encoders, TCM decoders, power supply units, power feeds, communication interfaces, communication protocols, etc. which are suitably arranged together to perform the technical solutions.

[0138] In particular, the processor of the controller 300, the network node 310 or the user equipment 320 can comprise one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, a special purpose computer chip, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that can interpret and execute instructions. The expression “processor” can thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones enumerated above. The processing circuitry can further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claims

1. A controller (300) for protected load balancing in a network, characterized in that, The network comprises the controller (300) and a plurality of network nodes (310), the controller (300) is configured to: obtain traffic information (301) of one or more tunnels in the network, wherein the traffic information (301) of each tunnel indicates a protection type of the tunnel against one or more failures; the protection type comprises no protection or protection; provide configuration information (302) to each network node (310) serving as a head-end node of a determined tunnel having a certain protection type according to the traffic information obtained for the determined tunnel, wherein the configuration information (302) comprises a bandwidth threshold and a load balancing configuration of the determined tunnel, the bandwidth threshold is used to instruct the network node (310) to send a notification (311) to the controller (300) when the traffic through the determined tunnel exceeds the bandwidth threshold, and the load balancing configuration is used to instruct the network node (310) how to split the traffic through the determined tunnel among a plurality of paths of the determined tunnel when a failure occurs; The configuration information (302) provided to each network node (310) serving as a head-end node of a determined tunnel according to the traffic information obtained for the determined tunnel having a certain protection type comprises: If it is determined that the determined tunnel is a protected tunnel, the configuration information (302) is provided to the head-end node of the determined tunnel.

2. The controller (300) according to claim 1, characterized in that The traffic information (301) of the one or more tunnels further comprises quality of service requirements and / or a traffic matrix comprising bandwidth estimates of the one or more tunnels.

3. The controller (300) according to claim 1 or 2, characterized in that The traffic information (301) of the one or more tunnels further indicates a set of shared risk link groups (SRLGs), each SRLG comprising a plurality of links of the one or more tunnels.

4. The controller (300) according to claim 3, characterized in that Further comprising: obtaining network information (303), wherein the network information (303) comprises a topology of the network and / or characteristics of one or more links of the one or more tunnels; determining the configuration information (302) according to the obtained traffic information (301) and the obtained network information (303).

5. The controller (300) according to claim 3, characterized in that The load balancing configuration of the determined tunnel is further used to indicate the plurality of paths of the determined tunnel and a split ratio of each path in the plurality of paths; The load balancing configuration of the determined tunnel is further used to instruct the network node (310) how to split the traffic through the determined tunnel among the plurality of paths when the failure is a failure of one SRLG in a set of SRLGs intersecting one or more paths of the determined tunnel.

6. The controller (300) according to claim 5, characterized in that Further comprising calculating the split ratio of each path using the obtained traffic information (301) such that the load of a path affected by the failure can be transferred to one or more other unaffected paths.

7. The controller (300) according to claim 5 or 6, characterized in that The configuration information (302) further comprises bandwidth reservation information for one or more paths of the determined tunnel.

8. The controller (300) according to claim 7, characterized in that The bandwidth reservation information includes bandwidth information shared by the one or more paths and / or bandwidth information for one path and not shared by other paths.

9. The controller (300) according to claim 1, characterized in that Further configured to: receive one or more notifications (311) from one or more of the network nodes (310), wherein each notification (311) is indicative of traffic over the one or more tunnels exceeding the bandwidth threshold or of a failure in the respective network node (310); adjust the configuration information (302) in accordance with the received one or more notifications (311).

10. The controller (300) according to claim 9, characterized in that Each notification (311) includes one or more of: the failure, abnormal traffic information, tunnel bandwidth information, current load balancing configuration, and local bandwidth threshold of the respective network node (310).

11. The controller (300) according to claim 9 or 10, characterized in that Further configured to: determine a protection status (304) of the one or more tunnels in accordance with the received one or more notifications (311), wherein the protection status (304) of each tunnel indicates whether the tunnel is protected in accordance with the protection type of the tunnel; provide the protection status (304) of the one or more tunnels.

12. The controller (300) according to claim 9, characterized in that Further configured to periodically adjust the configuration information (302) in accordance with the received one or more notifications and / or the obtained traffic information (301).

13. A network node (310) for protected load balancing in a network, characterized by, The network includes a controller (300) and a plurality of network nodes (310), the network nodes (310) being head-end nodes of a tunnel in the network, the network nodes (310) configured to: receive configuration information (302) from the controller (300), wherein the configuration information (302) includes a bandwidth threshold and a load balancing configuration of the tunnel, the bandwidth threshold being for indicating the network nodes (310) to send a notification (311) to the controller (300) when traffic over the tunnel exceeds the bandwidth threshold, the load balancing configuration being for indicating how the network nodes (310) split the traffic over the tunnel among a plurality of paths of the tunnel in the event of a failure; the configuration information (302) being provided by the controller (300) to the head-end nodes of the tunnel in accordance with traffic information (301) of the tunnel indicating a protection type of the tunnel against one or more failures, the protection type including unprotected or protected; send the notification (311) to the controller (300) in accordance with a determination that the traffic over the tunnel exceeds the bandwidth threshold.

14. The network node (310) according to claim 13, characterized by, Further configured to send the notification (311) to the controller (300) in accordance with a detection of a failure in the network nodes (310).

15. The network node (310) according to claim 13 or 14, characterized by, The load balancing configuration of the tunnel is for indicating the plurality of paths of the tunnel and a split ratio of each path of the plurality of paths, The load balancing configuration of the tunnel is configured to indicate to the network node how to split the traffic through the tunnel among the multiple paths when the failure is a failure of a shared risk link group (SLRG) intersecting one or more paths of the tunnel, the SLRG including multiple links of the one or more tunnels.

16. The network node (310) according to claim 15, characterized by, The traffic through the tunnel is also split among the multiple paths according to the split ratio included in the load balancing configuration of the tunnel.

17. The network node (310) according to claim 15, wherein The configuration information further includes bandwidth reservation information for one or more paths of the tunnel.

18. The network node (310) according to claim 17, characterized by, The bandwidth reservation information includes bandwidth information shared by the one or more paths and / or bandwidth information for one path and not shared by other paths.

19. The network node (310) according to claim 14, characterized by, The notification (311) includes one or more of: The failure, abnormal traffic information, tunnel bandwidth information, current load balancing configuration, and local bandwidth threshold of the corresponding network node.

20. A user equipment (320) for supporting protected load balancing in a network, characterized by, The network includes a controller (300) and multiple network nodes (310), and the user equipment (320) is configured to: provide the controller (300) with traffic information (301) of one or more tunnels in the network, wherein the traffic information (301) of each tunnel indicates a protection type of the tunnel against one or more failures; obtain the protection status (321) of the one or more tunnels from the controller (300), wherein the protection status of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel.

21. The user equipment (320) according to claim 20, characterized by The traffic information (301) of the one or more tunnels further includes quality of service requirements and / or a traffic matrix including bandwidth estimates of the one or more tunnels.

22. The user equipment (320) according to claim 20 or 21, characterized by The traffic information (320) of the one or more tunnels further indicates a set of shared risk link groups (SRLGs), each SRLG including multiple links of the one or more tunnels.

23. The user equipment (320) according to claim 22, characterized by The one or more failures include a failure of one SRLG in a set of SRLGs intersecting one or more paths of a tunnel.

24. A method (1000) for protected load balancing in a network, characterized by, The network includes a controller (300) and multiple network nodes (310), and the method includes the following steps performed by the controller (300): obtain (1001) traffic information (301) of one or more tunnels in the network, wherein the traffic information (301) of each tunnel indicates a protection type of the tunnel against one or more failures; the protection type includes no protection or protection; According to traffic information (301) obtained for a certain tunnel having a certain protection type, configuration information (302) is provided (1002) to each network node (310) that is a head-end node of the certain tunnel, wherein the configuration information (302) comprises a bandwidth threshold and a load balancing configuration of the certain tunnel, the bandwidth threshold being used to instruct the network node (310) to send a notification (311) to the controller (300) when traffic through the certain tunnel exceeds the bandwidth threshold, and the load balancing configuration being used to instruct the network node (310) how to split the traffic through the certain tunnel among multiple paths of the certain tunnel when a failure occurs; The providing of the configuration information (302) to each network node (310) that is a head-end node of the certain tunnel according to the traffic information obtained for a certain tunnel having a certain protection type comprises: If it is determined that the certain tunnel is a protected tunnel, the configuration information (302) is provided to the head-end node of the certain tunnel.

25. A method (1100) for protected load balancing in a network, characterized by, The network comprises a controller (300) and a plurality of network nodes (310), and the method (1100) comprises the following steps performed by a network node (310) that is a head-end node of a tunnel in the network: Receiving (1101) configuration information (302) from the controller (300), wherein the configuration information (302) comprises a bandwidth threshold and a load balancing configuration of the tunnel, the bandwidth threshold being used to instruct the network node (310) to send a notification (311) to the controller (300) when traffic through the tunnel exceeds the bandwidth threshold, and the load balancing configuration being used to instruct the network node (310) how to split the traffic through the tunnel among multiple paths of the tunnel when a failure occurs; the configuration information (302) is provided to the head-end node of the certain tunnel by the controller (300) according to traffic information (301) of the tunnel, which indicates a protection type of the tunnel against one or more failures, the protection type comprising no protection or protection; According to a determination that the traffic through the tunnel exceeds the bandwidth threshold, the notification (311) is sent (1102) to the controller (300).

26. A method (1200) for protected load balancing in a network, characterized by, The network comprises a controller (300) and a plurality of network nodes (310), and the method (1200) comprises the following steps performed by a user equipment (320) for supporting protected load balancing: Providing (1201) traffic information (301) of one or more tunnels in the network to the controller (300), wherein the traffic information (301) of each tunnel indicates a protection type of the tunnel against one or more failures; obtaining (1202) a protection status (304) of the one or more tunnels from the controller (300), wherein the protection status (304) of each tunnel indicates whether the tunnel is protected according to the protection type of the tunnel.

27. A computer program product comprising a program code, characterized in that, A computer program product for implementing the method according to any one of claims 24 to 26 when executed on a processor.

Images