WO2016029945A1

WO2016029945A1 - Method and controller for routing data packets in a software defined network

Info

Publication number: WO2016029945A1
Application number: PCT/EP2014/068224
Authority: WO
Inventors: Hayim Porat
Original assignee: Huawei Technologies Co.,Ltd
Priority date: 2014-08-28
Filing date: 2014-08-28
Publication date: 2016-03-03
Also published as: CN106664248A; CN106664248B

Abstract

The present invention relates to a method 100, 110 and SDN controller 301 for routing data packets in a Software Defined Network (SDN) 300. The SDN controller 301 configures a plurality of routes between any two edge switches in the network over all non-edge switches. A new data packet received at a source edge switch 302, or a header of said data packet, is forwarded to the SDN controller 301. The SDN controller 301 then selects one of the routes according to a destination edge switch 302 of the data packet, and configures only the source and destination edge switch 303, respectively, for sending the data packet along the selected route.

Description

METHOD AND CONTROLLER FOR ROUTING DATA PACKETS IN A SOFTWARE DEFINED NETWORK

TECHNICAL FIELD The present invention is directed to a method and a controller for routing data packets in a Software Defined Network (SDN). In particular, the present invention proposes to route data packets via rapid routes, which are pre-established over all hierarchal layers of a SDN.

BACKGROUND

In the state of the art, SDN is an emerging network technology addressing customization and optimization concerns. In SDN the data plane is decoupled from the control plane, and thus modern communication networks may be simplified. Typically, SDN employs the Open Flow (OF) protocol. According to the OF protocol, OF switches in the SDN are provided with flow tables containing entries concerning data packets, which define how and where the OF switch routes a certain data packet.

According to the specification of the OF protocol, whenever a flow table entry is absent or empty for a specific data packet arriving at an OF switch containing the flow table, a so called 'packet-in message' is sent by the OF switch to the SDN controller. The packet-in message causes the SDN controller to send in response a 'flow-mod command' to all OF switches in the SDN, in order to modify the state of the OF switches in view of the new data packet, i.e. in order to carry out a modification of their flow tables.

However, this behavior may result in various types of race conditions in accord with various data packet and message orderings. For example, as shown in Fig. 6, which illustrates a solution of the state of the art, when a flow-mod command message arrives at a switch Sn before the arrival of the same flow-mod command message at a switch Sn+1, it is possible that a new data packet is already sent from the switch Sn and arrives at the switch Sn+1 before the flow-mod command message is received at the switch Sn+1. In this scenario, a further packet-in message will be sent by the switch Sn+1, since the flow table of the switch Sn+1 is not yet modified for the new data packet. This may lead to a series of extra state transitions compared with a scenario, in which the flow-mod command message arrives at the switch Sn+1 before the data packet is received. The above-described problem of the OF protocol becomes worse with large scale multi-tier topologies.

In particular, in Fig. 6 at (1) a new data packet sent from HI to H2 arrives at switch SI. Since the switch SI does not have a flow table entry for the received data packet, it sends in (2) a message to the SDN controller. In (3) the SDN controller responds by sending a flow-mod command to all the switches SI to S4 in the network. In (4) the flow-mod command arrives at the switch SI, and the switch SI accordingly sends in (5) the data packet to switch S2. However, if the flow-mod command message did not yet arrive at the switch S2, the switch S2 will send in (6) an own packet-in message (including for example the data packet itself or a header thereof) to the SDN controller indicating it as a new data packet. One solution to the above-described problem would be to simply wait at the switch S2 for a certain amount of time before sending a packet-in message to the SDN controller, i.e. to wait, whether a flow-mod command message arrives from the SDN controller or not in a certain amount of time. However, particularly in larger topologies this will severely affect, i.e. slow down, the system performance. Some solutions for addressing the short comings of the OF protocol already exist in the prior art. For example, in one solution, since the SDN controller knows the exact path between an ingress and an egress node of a path for a data packet in the SDN, the SDN controller can relay path information to the ingress node, which is then embedded in a header that can be inserted into the data packet (optionally with some modifications to the OF protocol). This header is then inspected at each further node along the path of the data packet through the SDN. The intermediate nodes will not receive any state information from the SDN controller, since they will inspect the newly added header for forwarding decisions.

However, this solution requires major changes to the OF protocol, and is not compatible with legacy protocols and devices. Furthermore, the solution is prone to forwarding loops and/or black holes, because wrong configurations may not be detected, since all learning is from the headers. Finally, the solution is not well suited for protection and restoration. That is, the solution of the state of the art is based on pre-computed alternative links with no regards to capacity planning or QoS/SLA. Additionally, because restoration scenarios may result from countless events, there is no pre-computed solution for restoration in solution.

SUMMARY

In view of the above-mentioned disadvantages and problems, the present invention aims to improve the state of the art. In particular, the present invention intends to provide an improved solution for routing data packets in a SDN network. In particular, the object of the present invention is to provide an improved routing solution, which addresses the above-described problem of race conditions inherent to the OF protocol. Thereby, a major change of the OF protocol should be avoided, while compatibility with legacy protocols and devices should be ensured. Further, the solution of the present invention shall not hinder the performance of the system. The solution of the present invention should also be robust, and should provide options for protection and restoration.

The above-mentioned object of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the respective dependent claims. In particular, the core idea of the present invention is that instead of configuring the entire paths for every new data packet, the SDN controller maintains default connections between any two end points in the network, preferably using a full mesh of default paths, and for every new data packet, the SDN controller only configures the relevant edge switches and their association with the existing paths. A first aspect of the present invention provides a method for routing data packets in a SDN comprising: configuring, by an SDN controller, a plurality of routes between any two edge switches in the network over all non edge-switches, forwarding a new data packet received at a source edge switch, or a header of said data packet, to the SDN controller, selecting, by the SDN controller, one of the routes according to a destination edge switch of the data packet, and configuring, by the SDN controller, only the source and destination edge switch, respectively, for sending the data packet along the selected route.

Instead of trying to configure the entire path of the flow reactively, the SDN controller configures the plurality routes between any two edge switches in the network over all non-edges switches. As a result, the above-mentioned problem of race conditions inherent to the OF protocol is eliminated, because all routes are known and the only configuration required on the fly by the SDN controller is that of the source and destination edge switches. That is, it is not necessary for a new data packet to send flow-mod commands to all switches. When a new data packet enters the source edge switch, it is sent to the SDN controller (or alternatively a packet-in message is sent to the SDN controller, wherein the packet- in message may consist, for example, only of a header of the data packet), which chooses the appropriate route according to a destination edge switch of the data packet, and then only configures the source and destination edge switches. Because only the source and destination edge switch are configured (e.g. receive a flow-mod message), race conditions can be avoided, no changes are required to the OF protocol, and the routing through the SDN can be carried out rapidly and without huge impact on system performance.

In a first implementation form of the method according to the first aspect, the configuring of the source and destination edge switch comprises: instructing the source edge switch to send the data packet to the next network entity on the selected route.

Thereby, the new data packet is put on the desired route. Each further network entity on the selected route simply needs to forward the data packet according to the selected route. No configuration by the SDN controller of these intermediate entities is required. Thus, only the source edge switch needs to be configured by the SDN controller.

In a second implementation form of the method according to the first aspect or according to the first implementation form of the first aspect, the configuring of the source and destination edge switch comprises: instructing the source edge switch to send the data packet by tunneling. Thus, the method of the present invention supports tunneling, which may save memory space at the forwarding tables. Preferably, the user may decide, whether to use tunneling, in order to save memory space at the forwarding tables, or to use label switched routes (e.g. MPLS), in order to save on encapsulation. Tunneling is possible but not necessary.

In a third implementation form of the method according to the first aspect or according to any previous implementation form of the first aspect, the configuring of the source and destination edge switch comprises: creating a new entry related to the data packet in at least one flow table of the source and destination edge switch.

For example, when a new data packet is indicated by the source edge switch to the SDN controller, the SDN controller can send a flow-mod command to the source and destination edge switches, respectively, thereby operating according to the typical OF protocol. The new entry can relate the new data packet to the selected route, so that each further data packet is automatically sent on the selected route without further need for configuration.

In a fourth implementation form of the method according to the first aspect or according to any previous implementation form of the first aspect, the configuring of the plurality of routes comprises: creating one route for each possible connection between any two edge switches.

The SDN controller thus preferably maintains a full mesh of default data paths through the SDN. Thereby, the SDN controller has the greatest flexibility in choosing an appropriate route for a new data packet, and can efficiently perform load-balancing and/or protection (e.g. by choosing an alternative route in case of a route failure).

In a fifth implementation form of the method according to the first aspect or according to any previous implementation form of the first aspect, the method further comprises: monitoring, by the SDN controller, the flow of the data packet along the selected route, and changing, by the SDN controller, the selected route to a new route during the flow of the data packet, if a predetermined event is monitored.

The SDN controller is thereby able to change the route of a data packet on the fly. Thereby, greater flexibility is achieved, particularly for improved load balancing and protection. The SDN controller, by monitoring the flow of a data packet, can also calculate a new, e.g. more appropriate route for certain flows, e.g. for long-lived flows like FTP sessions or Telco services, certain appropriate routes may be selected. In a sixth implementation form of the method according to the first aspect or according to any previous implementation form of the first aspect, the selecting of the route for the data packet depends on one or more of: a source Internet Protocol, IP, address in the data packet header, a Type of Service, ToS, field entry in the data packet header, a priority assigned to the data packet, a current load distribution in the SDN.

Thus, the source edge switch may be configured by the SDN controller to send data packets on certain selected routes depending on the above-mentioned relevant criteria. Thus, different routes can be selected for different types of data packets. For instance, a route for lower priority data packets and a route for higher priority data packets may be pre-configured. Thereby, the routing of data packets through the SDN can be controlled more efficiently.

In a seventh implementation form of the method according to the first aspect or according to any previous implementation form of the first aspect, the configuring of the plurality of routes comprises: creating, in each of a plurality of hierarchic layers of the SDN, a plurality of forwarding equivalent routes, FERs, wherein each FER shares the same source and destination network entity in the hierarchic layer, but spans a different path.

The SDN controller is thus able to control the routing thorough each hierarchical layer separately. Different types of data packets may, for example, take different paths only in certain hierarchical layers, while they are routed on the same path in other hierarchical layers. Further, load balancing and/or protection may be achieved individually in each hierarchical layer, and may thus be carried out more efficiently.

In an eighth implementation form of the method according to the seventh implementation form of the first aspect, the configuring of the plurality of routes comprises: concatenating a plurality of FERs of different hierarchic layers to obtain a route.

The SDN controller is therefore more flexible in creating and/or re-creating the plurality of routes for the data packet.

In a ninth implementation form of the method according to the seventh or eighths implementation forms of the first aspect, the method further comprises: selecting, by the SDN controller, a new FER for routing the data packet through the associated hierarchic layer, if the FER in said hierarchic layer of the route for the data packet fails.

Thereby, the robustness of routing a data packet through the SDN can be improved.

In a tenth implementation form of the method according to any of the seventh to ninth implementation forms of the first aspect, the method further comprises: using, by the SDN controller, the plurality of FERs of a hierarchic layer for load balancing in said hierarchic layer.

Load balancing, in particular in each hierarchical layer, greatly improves the routing performance of data packets through the SDN. In an eleventh implementation form of the method according to any of the seventh to tenth implementation forms of the first aspect, the selecting of the route comprises: selecting the FER in the hierarchic layer containing the source edge switch by the SDN controller, and determining the FER in each other hierarchic layer by the respective source network entity contained in said hierarchic layer based on at least one pre- configured routing rule.

Thereby, on the one hand side the load on the SDN controller is lowered, and on the other hand side the selection of the route can be performed faster and more efficiently.

In a twelfth implementation form of the method according to the eleventh implementation form of the first aspect, the at least one pre-configured routing rule is based on a class and/or a priority of the data packet.

Thus, different routes for different data packets may be selected within each hierarchical layer depending on class and/or priority of the data packet.

A second aspect of the present invention provides a method for routing data packets in a Software Defined Network, SDN, comprising: configuring, by an SDN controller, a plurality of routes between any two edge switches in the network over all switches, and forwarding a new data packet received at a source edge switch over a pre-configured route.

The second aspect presents an alternative method to the method of the first aspect. By pre-configuring the plurality of routes by the SDN controller, the danger of race conditions mentioned above as being inherent to the OF protocol can be avoided, while at the same time the OF protocol can be used without modifications.

In a first implementation form of the method according to the second aspect, the method further comprising: forwarding, by the source edge switch, the new data packet received at the source edge switch, or a header of said data packet, to the SDN controller, for update.

The source edge switch thus informs the SDN controller of the arrival of a new data packet, which e.g. allows the SDN controller to make modifications to the pre- configured route if necessary. In a second implementation form of the method according to the second aspect or according to the first implementation form of the second aspect, the method further comprises: monitoring, by the SDN controller, the flow of the data packet along the pre-configured route, and changing, by the SDN controller, the pre-configured route to a new route during the flow of the data packet, if a predetermined event is monitored. In a third implementation form of the method according to the second aspect or according to any of the previous implementation forms of the second aspect, the configuring of the plurality of routes comprises: creating, in each of a plurality of hierarchic layers of the SDN, a plurality of forwarding equivalent routes, FERs, wherein each FER shares the same source and destination network entity in the hierarchic layer, but spans a different path.

In a fourth implementation form of the method according to the third implementation form of the second aspect, the configuring of the plurality of routes comprises: concatenating a plurality of FERs of different hierarchic layers to obtain a route.

In a fifth implementation form of the method according to the third or fourth implementation forms of the second aspect, the method further comprises: selecting, by the SDN controller, a new FER for routing the data packet through the associated hierarchic layer, if the FER in said hierarchic layer of the route for the data packet fails.

In a sixth implementation form of the method according to any of the third to fifth implementation forms of the second aspect, the method further comprises: using, by the SDN controller, the plurality of FERs of a hierarchic layer for load balancing in said hierarchic layer.

The second to sixth implementation form of the second aspect have the same advantages as the fifth to ninth implementation forms of the first aspect, respectively. A third aspect of the present invention provides a SDN controller for routing data packets in a Software Defined Network, SDN, comprising: a routing unit adapted to configure a plurality of routes between any two edge switches in the network over all non edge-switches, a receiving unit adapted to receive a new data packet, or a header of said data packet, from a source edge switch, a selecting unit adapted to select one of the routes according to a destination edge switch for the data packet, and a configuration unit adapted to configure only the source and destination edge switch, respectively, for sending the data packet along the selected route.

In a first implementation form of the SDN controller according to the third aspect, the configuration unit is adapted, for configuring the source and destination edge switch, to instruct the source edge switch to send the data packet to the next network entity on the selected route.

In a second implementation form of the SDN controller according to the third aspect or according to the first implementation form of the third aspect, the configuration unit is adapted, for configuring the source and destination edge switch comprises, to instruct the source edge switch to send the data packet by tunneling.

In a third implementation form of the SDN controller according to the third aspect or according to any previous implementation form of the third aspect, the configuration unit is adapted, for configuring the source and destination edge switch, to create a new entry related to the data packet in at least one flow table of the source and destination edge switch.

In a fourth implementation form of the SDN controller according to the third aspect or according to any previous implementation form of the third aspect, the routing unit is adapted, for configuring the plurality of routes, to create at least one route for each possible connection between any two edge switches. In a fifth implementation form of the SDN controller according to the third aspect or according to any previous implementation form of the third aspect, the SDN controller further comprises: a monitoring unit adapted to monitor the flow of the data packet along the selected route, and the selecting unit is adapted to change the selected route to a new route during the flow of the data packet, if a predetermined event is monitored.

In a sixth implementation form of the SDN controller according to the third aspect or according to any previous implementation form of the third aspect, the selecting unit is adapted, to select the route for the data packet depending on one or more of: a source Internet Protocol, IP, address in the data packet header, a Type of Service, ToS, field entry in the data packet header, a priority assigned to the data packet, a current load distribution in the SDN.

In a seventh implementation form of the SDN controller according to the third aspect or according to any previous implementation form of the third aspect, the routing unit is adapted, for configuring the plurality of routes, to create, in each of a plurality of hierarchic layers of the SDN, a plurality of forwarding equivalent routes, FERs, wherein each FER shares the same source and destination network entity in the hierarchic layer, but spans a different path.

In an eighth implementation form of the SDN controller according to the seventh implementation form of the third aspect, the routing unit is adapted, for configuring the plurality of routes, to concatenate a plurality of FERs of different hierarchic layers to obtain a route.

In a ninth implementation form of the SDN controller according to the seventh or eighths implementation forms of the third aspect, the selecting unit is configured to select a new FER for routing the data packet through the associated hierarchic layer, if the FER in said hierarchic layer of the route for the data packet fails.

In a tenth implementation form of the SDN controller according to any of the seventh to ninth implementation forms of the third aspect, the SDN controller is further adapted to use the plurality of FERs of a hierarchic layer for load balancing in said hierarchic layer. In an eleventh implementation form of the SDN controller according to any of the seventh to tenth implementation forms of the third aspect, the selecting unit is adapted, for selecting the route, to selecting the FER in the hierarchic layer containing the source edge switch by the SND controller, and to determine the FER in each other hierarchic layer by the respective source network entity contained in said hierarchic layer based on at least one pre-configured routing rule. In a twelfth implementation form of the SDN controller according to the eleventh implementation form of the third aspect, the at least one pre-configured routing rule is based on a class and/or a priority of the data packet.

The SDN controller of the third aspect has the same advantages as the method of the first aspect. A fourth aspect of the present invention provides a computer program comprising a program code for performing, when running on a computer, the method according to the first aspect, the second aspect or any implementation form thereof.

Since the computer program allows running the above-mentioned method, the same advantages as by the method of the first aspect and second aspect, respectively can be achieved.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be full formed by eternal entities not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

Fig. 1 shows basic embodiments of methods according to the present invention.

Fig. 2 shows a basic embodiment of a SDN controller according to the present invention.

Fig. 3 shows a routing scheme according to the present invention.

Fig. 4 shows a routing scheme according to an embodiment of the present invention.

Fig. 5 shows a flow diagram with method steps according to an embodiment of the present invention.

Fig. 6 shows a routing according to the prior art.

DETAILED DESCRIPION OF EMBODIMENTS

Figure 1 shows in (a) a basic method 100 according to an embodiment of the present invention. In a first step 101, an SDN controller configures a plurality of routes between any two edge switches in the network over all non-edge switches. In a second step 102, a new data packet received at a source edge switch is forwarded by the source edge switch to the SDN controller, for instance as a 'packet- in message' . Alternatively, only a header of the data packet is forwarded by the edge switch to the SDN controller.

In a third step 103, the SDN controller selects one of the routes according to a destination edge switch of the data packet. Finally, in a fourth step 104 the SDN controller configures the source and destination edge switch, respectively, for sending the data packet along the selected route. For example, the SDN controller sends a 'flow-mod command' to the source and destination edge switches, respectively, in order to modify a flow table entry of these switches according to the new data packet.

Figure 1 shows in (b) an alternative basic method 110 according to an embodiment of the present invention. In a first step 111, an SDN controller configures a plurality of routes between any two edge switches in the network over all switches. In a second step 112, a new data packet received at a source edge switch is forwarded over a preconfigured route.

Figure 2 shows a basic SDN controller 200 according to an embodiment of the present invention. The SDN controller 200 is particularly configured to carry out the method steps of the method 100 and/or the method 110 shown in Fig. 1. The SDN controller 200 comprises at least a routing unit 201, a receiving unit 202, a selecting unit 203, and a configuration unit 204. Each of these units 201 to 204 may carry out a method step of the method 100 shown in Fig.l . However, the units 201 to 204 can also be included in a larger unit, for example, a micro-controller or a processor, which carries out individual functions according to the method steps of the method 100.

The routing unit 201 is at least adapted to configure a plurality of routes between any two edge switches in the network over all non-edge switches. The receiving unit 202 is at least adapted to receive new data packets, or a header of said data packets, from a source edge switch, and to inform the selecting unit 203 accordingly. The selecting unit 203 is then at least adapted to select one of the routes established by the routing unit 201 according to a destination edge switch for the data packet. The destination edge switch of the data packet is, for example, contained in the data packet header.

Finally, according to the selection of the selecting unit 203, the configuration unit 204 is at least configured to configure only the source and destination edge switch intended for the data packet, in order to send the data packet along the selected route. The configuring of the source and destination edge switch is achieved, for example, by modifying a flow table entry, which causes the edge switches to send the data packet along the selected route.

Figure 3 shows an embodiment of the present invention, which is an extension to the basic embodiments shown in Fig. 1 and Fig. 2, respectively. In particular, Fig. 3 shows a SDN 300, in which at least a SDN controller 301 and a plurality of edge switches are contained. The SDN 300 of Fig. 3 comprises different network hierarchies, in particular three hierarchic layers named 'Edge', 'Agg' and 'Core', respectively. This is, however, only exemplary, and the present invention may also be applied in an SDN with only one hierarchic layer, or in an SDN with more than three hierarchic layers. A data packet arriving from HI is intended to be sent via the SDN 300 to H2. Thereby, the data packet is received from HI by a source edge switch 302 and is sent to H2 by a destination edge switch 303.

According to the solution of the present invention, a SDN controller 301 configures a plurality of routes through the SDN 300 from the source edge switch 302 to the destination edge switch 303. Preferably, the SDN controller 301 configures several possible connections between the source edge switch 302 and the destination edge switch 303, i.e. several possible network nodes in the one or more hierarchic layers of the SDN. As soon as the new data packet arrives at the source edge switch 302, the source edge switch 302 sends the data packet, or a header of the data packet, to the SDN controller 301. The SDN controller 301 then decides on the path, i.e. the route, which the data packet should take through the SDN 300, and establishes a connection by configuring the source and destination edge switches 302 and 303, respectively. If only one possible route through the SDN 300 exists, it is also possible that the source edge switch 302 routes the packet directly, i.e. without sending the data packet or its header to the SDN controller 301.

In particular, for the SDN 300 shown in Fig. 3 having three hierarchic layers (Edge, Agg (Aggregation) and Core), and especially for fabric networks such as clos, hypercube, fat tree, etc. there are several path between a hierarchic layer and the hierarchic layer above and below. Therefore, the SDN controller 301 may create a plurality of routes through the different hierarchic layers, preferably a connection between each node in each hierarchic layer. The SDN controller 301 may particularly create so called Forwarding Equivalent Routes (FERs), wherein each FER shares the same source and destination network entity in a hierarchic layer, but spans a different path. As can be seen in Fig. 3, there are several sets of these FERs, for example, C and D are FERs between the Agg layer and the Core layer (called 'first hierarchy FERs'), or A and B are FERs between the Edge layer and the Agg layer (called 'second hierarchy FERs'). For instance, C and D have the same source and destination entity in the Agg layer, but span different paths between the Agg layer and the Core layer. A and B have the same source and destination edge switch in the Edge layer, but span different paths between the Edge layer and the Agg layer.

The FERs are preferably created by the SDN controller 301, and FERs of different hierarchy may be concatenated between the individual hierarchic layers, in order to form the plurality of routes between any two edges switches in the network. For example, in Fig. 3 the first hierarchy FERs may be concatenated with the second hierarchy FERs. Thereby, the FERs of each hierarchy may be controlled separately. Each hierarchic layer may maintain its own set of FERs.

In Fig. 3, a path between HI and H2 may take a route that is concatenated by different FERs of different hierarchies, for example, a packet sent from HI to H2 may traverse A^C^B or A^D^B. The SDN controller 301 preferably determines which route a data packet is to take when it receives a packet-in message from the source edge switch 302. The decision by the SDN controller 301 about which route to take can, for example, be based on a source IP address in the data packet header, a type of service field entry in the data packet header, a priority assigned to the data packet, a current load distribution in the SDN 300, or the like. When the SDN controller 301 has chosen the route, the source edge switch 302 tells the data packet to go on a certain route, and all subsequent data packets of the data flow are then sent along this route without any further necessity of the SDN controller 301 to configure different network entities along the route.

In case of a failure of a route selected by the SDN controller 301, or in case of a failure of an FER of the selected route in one hierarchy, it is possible to automatically choose a different route of FER. The FERs of each hierarchy may also be employed for protection or load balancing. Within each hierarchy the data packet may be sent via labeled switched routing along the FERs or by tunneling.

The SDN controller 301 is further able to monitor the flow of the data packet along the selected route, and if necessary choose a new route for a relevant data packet or flow (for example, long lived ones such as FTP sessions or carrier services). Each newly selected route may again be a concatenation of several FERs in different hierarchies. Thereby, a better aliment with fabric architectures can be achieved than with standard routine mechanisms. Figure 4 shows another embodiment of the present invention, which is an extension of the previously shown embodiment. As in Fig. 3 multiple routes are established by the SDN controller 301 between each hierarchic layer. For example, the route 2 and the route 3 are two possible routes from the source edge switch 302 to the destination edge switch 303. As described previously, the SDN controller 301 is able to choose for each new packet arriving at the edge source switch 302 a route through the SDN 300. Thereby, it is possible to select different default routes from HI to H2 for different data packets or for different classes of flows. For example, the route 2 can be chosen for data packets having a higher priority, and the route 3 can be chosen for data packets having a lower priority. Different routes can be also used for short term flows and long term flows (such as FTP, carrier service etc.), respectively. This is completely different from the default gateway concept in typical routing, which one (and only one) next hop for sending all unknown data packets as designated.

Figure 5 shows a flow diagram of a method 500 according to an embodiment of the present invention. The embodiment is an extension of the method 100 or 110 shown in Fig. 1. In Fig. 5 in a step 501 an SDN application is run on an SDN controller 301. Then, in step 502, the SDN is partitioned into N hierarchic layers. For example, the SDN 300 shown in Fig. 3 is partitioned into three hierarchic layers. In step 503 connections between any two ports may be created in each hierarchic level. The connections are the FERs mentioned above. Preferably, each FER is assigned a route ID. In step 504 a minimum set of routes is configured, in order to enable connectivity between any two entities in the SDN on each hierarchic level. Afterwards, the system waits for connection in step 505. The steps 502 to 504 corresponds to steps 101 or 111 shown in Fig. 1, i.e. is an extension thereof. In step 506 the first data packet of a data flow arrives at a source edge switch 302. In step 507 the SDN controller 301 configures the relevant end points, i.e. the source and destination edge switches 302 and 304 and assigns a default route for sending the data packet though the SDN. Thereby, optionally the SDN controller configures for tunneling. Step 507 correspond to the steps 103 and 104 shown in Fig. 1. In step 508 the first data packet is sent via the selected pre-configured route. Preferably, the SDN controller 301 monitors the flow of the data packet as in step 509. The SDN controller 301 may determine, whether the data packet deserves an optimized or alternative route, for example, because it is a long-lived flow such as an FTP session or a Telco service. If the SDN controller 301 determines that an optimized or alternative route is required, the SDN controller 301 calculates a new route and configures the relevant network entities accordingly, so that the data packet is sent along the new route. After computing a new route, or if no need for an optimized or alternative route was determined, the flow end is reached.

In summary, in the present invention an SDN controller pre-configures a plurality routes between any two edge switches in a SDN over all non-edges switches. As a result, a problem of race conditions as known in the OF protocol can be eliminated or at least reduced because all routes are known and the only configuration required on the fly by the SDN controller is that of the source and destination edge switches.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

Method (100) for routing data packets in a Software Defined Network, SDN, (300) comprising: configuring (101), by an SDN controller (200), a plurality of routes between any two edge switches in the network over all non-edge switches, forwarding (102) a new data packet received at a source edge switch (302), or a header of said data packet, to the SDN controller (200), selecting (103), by the SDN controller (200), one of the routes according to a destination edge switch (303) of the data packet, and configuring (104), by the SDN controller (200), only the source and destination edge switch (302, 303), respectively, for sending the data packet along the selected route.

Method (100) according to claim 1, wherein the configuring (104) of the source and destination edge switch (302, 303) comprises: instructing the source edge switch (302) to send the data packet to the next network entity on the selected route.

Method (100) according to claim 1 or 2, wherein the configuring (104) of the source and destination edge switch (302, 303) comprises: instructing the source edge switch (302) to send the data packet by tunneling.

Method (100) according to one of the claims 1 to 3, wherein the configuring (104) of the source and destination edge switch (302, 304) comprises: creating a new entry related to the data packet in at least one flow table of the source and destination edge switch (302, 303).

Method (100) according to one of the claims 1 to 4, wherein the configuring (101) of the plurality of routes comprises: creating at least one route for each possible connection between any two edge switches.

6. Method (100) according to one of the claims 1 to 5, further comprising:

Monitoring, by the SDN controller (200), the flow of the data packet along the selected route, and changing, by the SDN controller (200), the selected route to a new route during the flow of the data packet, if a predetermined event is monitored.

7. Method (100) according to one of the claims 1 to 6, wherein the selecting (103) of the route for the data packet depends on one or more of:

- a source Internet Protocol, IP, address in the data packet header,

- a Type of Service, ToS, field entry in the data packet header,

- a priority assigned to the data packet,

- a current load distribution in the SDN.

8. Method (110) for routing data packets in a Software Defined Network, SDN,

comprising: configuring (111), by an SDN controller (200), a plurality of routes between any two edge switches in the network over all switches, and forwarding (112) a new data packet received at a source edge switch (302) over a pre- configured route.

9. Method (110) according to claim 8, further comprising: forwarding, by the source edge switch (302), the new data packet received at the source edge switch (302), or a header of said data packet, to the SDN controller (200), for update.

10. Method (110) according to claim 8 or 9, further comprising: monitoring, by the SDN controller (200), the flow of the data packet along the pre- configured route, and changing, by the SDN controller (200), the pre-configured route to a new route during the flow of the data packet, if a predetermined event is monitored.

11. Method (100, 110) according to one of the claims 1 to 10, wherein the configuring (101, 111) of the plurality of routes comprises: creating, in each of a plurality of hierarchic layers of the SDN (300), a plurality of forwarding equivalent routes, FERs, wherein each FER shares the same source and destination network entity in the hierarchic layer, but spans a different path.

12. Method (100, 110) according to claim 11, wherein the configuring (101, 111) of the plurality of routes comprises: concatenating a plurality of FERs of different hierarchic layers to obtain a route.

13. Method (100, 110) according to claim 11 or 12, further comprising: selecting, by the SDN controller (200), a new FER for routing the data packet through the associated hierarchic layer, if the FER in said hierarchic layer of the route for the data packet fails.

14. Method (100, 110) according to one of the claims 11 to 13, further comprising: using, by the SDN controller (200), the plurality of FERs of a hierarchic layer for load balancing in said hierarchic layer.

15. Method (100) according to one of the claims 11 to 14 when depending on one of the claims 1 to 7, wherein the selecting (103) of the route comprises: selecting the FER in the hierarchic layer containing the source edge switch (302) by the SND controller (200), and determining the FER in each other hierarchic layer by the respective source network entity contained in said hierarchic layer based on at least one pre-configured routing rule.

16. Method (100) according to claim 15, wherein the at least one pre-configured routing rule is based on a class and/or a priority of the data packet.

17. SDN controller (200) for routing data packets in a Software Defined Network,

SDN, (300) comprising: a routing unit (201) adapted to configure a plurality of routes between any two edge switches in the network over all non-edge switches, a receiving unit (202) adapted to receive a new data packet, or a header of said data packet, from a source edge switch (302), a selecting unit (203) adapted to select one of the routes according to a destination edge switch (303) for the data packet, and a configuration unit (204) adapted to configure only the source and destination edge switch (302, 303), respectively, for sending the data packet along the selected route.

A computer program comprising a program code for performing, when running on a computer, the method (100, 110) according to one of the claims 1 to 16.