WO2017198307A1

WO2017198307A1 - Controller and switch for control plane traffic control in software defined networks

Info

Publication number: WO2017198307A1
Application number: PCT/EP2016/061367
Authority: WO
Inventors: Ramin KHALILI; Zoran Despotovic; David Perez; Artur Hecker
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2016-05-20
Filing date: 2016-05-20
Publication date: 2017-11-23

Abstract

The invention relates to a controller (110) configured to control the forwarding of control data packets within a software defined network (100), wherein the controller (110) can be connected with a data packet forwarding unit (120a-c) via at least two TCP connections (138, 139), wherein the controller (110) comprises: a first path manager (113) and a second path manager (117), wherein the first path manager (113) is configured in response to a request from the data packet forwarding unit (120a-c) to establish a TCP connection (138, 139) between the controller (110) and the data packet forwarding unit (120a-c) and to inform the second path manager (117) about the TCP connection (138, 139) between the controller (110) and the data packet forwarding unit (120a-c), and wherein the second path manager (117) is configured to determine a data packet path for the TCP connection (138, 139) between the controller (110) and the data packet forwarding unit (120a-c) and to provide a respective set of data packet forwarding rules to each data packet forwarding unit (120a-c) located along the data packet path for the TCP connection (138, 139), wherein the sets of data packet forwarding rules define for each TCP connection (138, 139) between the controller (110) and the data packet forwarding unit (120a-c) a unique data packet path between the controller (110) and the data packet forwarding unit (120a-c).

Description

CONTROLLER AND SWITCH FOR CONTROL PLANE TRAFFIC CONTROL IN

SOFTWARE DEFINED NETWORKS

TECHNICAL FIELD

In general, the present invention relates to software defined networks. More specifically, the present invention relates to a controller and a switch for control plane traffic control in software defined networks. BACKGROUND

Software-Defined Networking (SDN) has emerged as the paradigm to change the way computer networks are designed and operated. The fundamental change introduced by SDN is the separation of the network control plane from the data plane forwarding function. In other words, in a software-defined network a switch is generally responsible just for forwarding data packets (i.e. data plane), while the logic behind any forwarding decisions (i.e. control plane) is maintained by a logically centralized SDN controller and distributed to the switches via suitable protocols, such as OpenFlow (OF). To communicate with a SDN controller using a protocol such as OpenFlow, a switch needs to establish a TCP connection on a well-defined port. Using single-path TCP connections results in reliability issues in in-band configuration, where the control plane reconfiguration messages reach the switch via the data plane forwarding plane. In this configuration, when a link or a port on the path from a switch to the SDN controller fails, the affected switch will be not accessible and hence cannot be controlled. The SDN controller can detect the failure only after a timeout occurs at the TCP layer which indicates that the connection to the switch has failed. The SDN controller therefore reestablishes its connection to the switch by re-routing traffic over a new path, which is illustrated by the exemplary communication network 100 shown in figure 1 . If the link between the switch S2 120a and the switch S1 120b fails, the switch S2 120a would no longer be accessible via the path "switch S2"-"switch S1 "-"controller", and hence the controller 1 10 needs to establish a new connection to the switch S2 120a via the path "switch S2"-"switch S3"-"controller".

In addition to this type of link failures a failure can also occur, when an OF-relay, which could be implemented by the switch S2 120a shown in figure 1 , fails or an OF-relaying port is miss-configured to not correctly forward OF traffic anymore. The time required for detecting the failure, correcting the routing paths, and setting up a new connection to the switch is potentially very long, which could negatively affect the performance of the network.

Different control applications could easily issue command sequences that inadvertently result in some of the failures described above, therefore leading to self-induced errors. The correct syntax depends on the context, situation and network topology and is hard to synchronize between different applications. Assuming that for in-band configuration the data plane auto-heals is contradictory to the central idea of SDN, namely to push all intelligence into the controller. This simply means that switches have to be able to detect a failure and to be able to recover from the failure, by routing via other paths to the controller, all without help of the controller. This requires the use of a distributed routing and a distributed fail detection algorithm by the switches, which is contradictory to the idea of SDN. The use of out-of-band connections between the controller and the switches

(where the controller is directly connected to the switches) is also very costly especially in large networks.

By providing multipath (i.e. redundant) communication between switches and the controller in a software-defined network the reliability of the control plane can be improved. Multipath TCP (MPTCP) is an extension to TCP which enables multipath communication between two devices by splitting a TCP connection into multiple TCP connections, each of which is transmitted over one of the paths, as illustrated in figure 2. MPTCP can provide reliable communication between two network devices in that if one path between the network devices fails, its traffic can be re-forwarded over the other path automatically. MPTCP is transparent to applications where all decisions and modifications are applied at the TCP layer, so the applications are not even aware of multipath TCP connections. MPTCP is standardized at IETF and is implemented, for instance, in the Linux kernel.

However, simply implementing MPTCP in a communication network cannot address the problems described above in the context of the SDN control plane scenario shown in figure 1 for the following reasons. Firstly, MPTCP is designed for (IP) multi-homed end-users, which is not the case in SDN control planes. A multi-homed user is connected to different networks domains using different network interfaces, each with a different IP address. Hence, MPTCP can establish multiple connections to the user using these different IP addresses, guaranteeing that these paths are at least partially disjoint as they cross different network domains. To have such a setting in the control plane of a SDN would require a controller with different interfaces, each connected to a different network domain. Although in principle possible, this would require dedicated and duplicated control plane networks, which is very costly.

Secondly, MPTCP is configured to transmit different packets over different TCP connections and to retransmit a lost packet (after detecting the loss) over the other TCP connections, which can potentially increase the latency.

Thus, by just replacing TCP with MPTCP, nothing would happen in the exemplary scenario shown in figure 1 and the communication between the switches and the controller would be still carried over a single path.

Thus, there is a need for improved devices and methods for traffic control in the control plane of software defined networks, in particular an improved controller and an improved switch for traffic control in software defined networks allowing improving the reliability of the control plane of a software-defined network by providing multipath communication between switches and the controller.

SUMMARY It is an object of the invention to provide for improved devices and methods for control plane traffic control in software defined networks, in particular an improved controller and an improved switch for traffic control in the control plane of software defined networks allowing improving the reliability of the control plane of a software-defined network by providing multipath communication between switches and the controller.

The foregoing and other objects are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures. According to a first aspect, the invention relates to a controller configured to control forwarding of control data packets within a software defined network, in particular within the control plane of a software defined network, wherein the controller can be connected with a data packet forwarding unit, in particular a switch, via at least two transmission control protocol (TCP) control connections. The data packet forwarding unit is configured to forward control data packets on the basis of a set of data packet forwarding rules. The controller comprises: a first path manager and a second path manager. The first path manager is configured in response to a request from the data packet forwarding unit to establish together with the data packet forwarding unit a TCP control connection between the controller and the data packet forwarding unit and to inform, i.e. notify, the second path manager about the TCP control connection between the controller and the data packet forwarding unit. The TCP control connection between the controller and the data packet forwarding unit can be an additional TCP control connection to an already existing TCP control connection between the controller and the data packet forwarding unit. The second path manager is configured to determine a control data packet path for the TCP control connection between the controller and the data packet forwarding unit and to provide a respective set of data packet forwarding rules to each data packet forwarding unit located along the control data packet path for the TCP control connection, wherein the sets of data packet forwarding rules define for each TCP control connection between the controller and the data packet forwarding unit a unique control data packet path between the controller and the data packet forwarding unit. The plurality of TCP control connections can be created across the same pair of IP addresses of the controller and the data packet forwarding unit.

Thus, an improved controller for traffic control in software defined networks is provided allowing improving the reliability of the control plane of a software-defined network by providing multipath communication between switches and the controller.

In a first possible implementation form of the controller according to the first aspect as such, the first path manager is implemented in the transport layer of a TCP stack of the controller and/or the second path manager is implemented in the application plane of the software defined network.

In a second possible implementation form of the controller according to the first aspect as such or the first implementation form thereof, the first path manager is implemented as a part of a Multipath TCP kernel of the controller. In a third possible implementation form of the controller according to the first aspect as such or the first or second implementation form thereof, the controller further comprises a scheduler, wherein the first path manager is further configured to inform the scheduler about the TCP control connection between the controller and the data packet forwarding unit and wherein the scheduler is configured to allocate control data packets to the at least two TCP control connections between the controller and the data packet forwarding unit for data packet transmission.

In a fourth possible implementation form of the controller according to the third

implementation form of the first aspect, the scheduler is further configured to allocate at least one control data packet to a first TCP control connection and at least one additional TCP control connection of the at least two TCP control connections between the controller and the data packet forwarding unit for data packet transmission. In a fifth possible implementation form of the controller according to the fourth

implementation form of the first aspect, the scheduler is further configured to determine the number of additional TCP control connections between the controller and the data packet forwarding unit on the basis of a message type associated with the control data packets. Message types could be, for instance, "high priority message" and "low priority message". Thus, in an implementation form, the scheduler can be configured to assign the control data packets of control messages of the type "high priority message" to more additional TCP control connections than control data packets of messages of the type "low priority message". In a sixth possible implementation form of the controller according to the first aspect as such or any one of the first to fifth implementation form thereof, the first path manager is configured to dynamically adjust the number of TCP connections between the controller and the data packet forwarding unit by keeping the number of TCP connections above a lower threshold.

In a seventh possible implementation form of the controller according to the sixth implementation form of the first aspect, the second path manager is configured to determine the lower threshold for the number of TCP connections between the controller and the data packet forwarding unit on the basis of a status of the software defined network. According to a second aspect, the invention relates to a data packet forwarding unit, in particular a switch, configured to forward control data packets within a software defined network managed on the basis of a set of data packet forwarding rules, wherein the data packet forwarding unit comprises a path manager configured to dynamically adjust the number of at least two TCP control connections between the data packet forwarding unit and a controller configured to control the forwarding of control data packets within the software defined network.

Thus, an improved data packet forwarding unit, in particular switch, for control plane traffic control in software defined networks is provided allowing improving the reliability of the control plane of a software defined network by providing multipath communication between switches and the controller. The path manager can be implemented as part of a MPTCP enabled kernel of the data packet forwarding unit. The data packet forwarding unit can be, for instance, an open flow (OF) only switch or a hybrid switch.

In a first possible implementation form of the data packet forwarding unit according to the second aspect as such, the path manager is configured to assign different TCP source ports to the at least two TCP control connections between the data packet forwarding unit and the controller.

In a second possible implementation form of the data packet forwarding unit according to the second aspect as such or the first implementation form thereof, the path manager is configured to dynamically adjust the number of TCP control connections between the data packet forwarding unit and the controller by keeping the number of TCP control connections between the data packet forwarding unit and the controller above a lower threshold. Maintaining a minimum number of TCP control connections allows ensuring a minimum "quality of service". In principle, each switch could have a switch-specific lower predefined threshold. The lower threshold can be determined by the second path manager module at the controller. Preferably, the lower threshold is more than one TCP control connection.

In a third possible implementation form of the data packet forwarding unit according to the second aspect as such or the first or second implementation form thereof, the path manager is configured to adjust the lower threshold for the number of TCP control connections between the data packet forwarding unit and the controller on the basis of the status of its established connections to the controller. For instance, for unstable network conditions the lower threshold can be increased.

In a fourth possible implementation form of the data packet forwarding unit according to the second or third implementation form of the second aspect, the path manager is configured to receive the lower threshold for the number of TCP connections between the data packet forwarding unit and the controller from the controller.

In a fifth possible implementation form of the data packet forwarding unit according to the second aspect as such or any one of the first to fourth implementation form thereof, the data packet forwarding unit further comprises a scheduler configured to allocate control data packets to the at least two TCP control connections between the data packet forwarding unit and the controller. According to a third aspect, the invention relates to a SDN system comprising a controller according to the first aspect as such or any one of the first to fifth implementation form thereof and at least two data packet forwarding units, in particular switches, according to the second aspect as such or any one of the first to fourth implementation form thereof. According to a fourth aspect, the invention relates to a method of operating a controller configured to control forwarding of control data packets within a software defined network, wherein the controller can be connected with a data packet forwarding unit via at least two transmission control protocol (TCP) control connections. The method comprises the steps of: establishing in response to a request from the data packet forwarding unit a TCP control connection between the controller and the data packet forwarding unit; determining a control data packet path for the TCP control connection between the controller and the data packet forwarding unit; and providing a respective set of data packet forwarding rules to each data packet forwarding unit located along the control data packet path for the TCP control connection between the controller and the data packet forwarding unit, wherein the sets of data packet forwarding rules define for each TCP control connection between the controller and the data packet forwarding unit a unique control data packet path between the controller and the data packet forwarding unit.

The method according to the fourth aspect of the invention can be performed by the controller according to the first aspect of the invention. Further features of the method according to the fourth aspect of the invention result directly from the functionality of the controller according to the first aspect of the invention and its different implementation forms.

According to a fifth aspect, the invention relates to a method of operating a data packet forwarding unit, in particular a switch, configured to forward control data packets within a software defined network on the basis of a set of data packet forwarding rules, wherein the method comprises the step of dynamically adjusting the number of at least two transmission control protocol (TCP) connections between the data packet forwarding unit and a controller configured to control the forwarding of control data packets within the software defined network.

The method according to the fifth aspect of the invention can be performed by the data packet forwarding unit according to the second aspect of the invention. Further features of the method according to the fifth aspect of the invention result directly from the

functionality of the data packet forwarding unit according to the second aspect of the invention and its different implementation forms.

According to a sixth aspect the invention relates to a computer program comprising program code for performing the method according to the fourth aspect or the fifth aspect of the invention when executed on a computer.

The invention can be implemented in hardware and/or software.

BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments of the invention will be described with respect to the following figures, wherein:

Fig. 1 shows a schematic diagram of a software-defined network including a controller and three switches;

Fig. 2 shows a schematic diagram illustrating the multipath communication provided by MPTCP;

Fig. 3 shows a schematic diagram illustrating a controller and a switch according to an embodiment; Fig. 4 shows a schematic diagram illustrating an exemplary scenario in a software-defined network including a controller and three switches according to an embodiment;

Fig. 5 shows a schematic diagram illustrating an exemplary scenario in a software-defined network including a controller and three switches according to an embodiment;

Fig. 6 shows a schematic diagram illustrating a method of operating a controller of a software-defined network according to an embodiment; and Fig. 7 shows a schematic diagram illustrating a method of operating a switch of a software-defined network according to an embodiment.

In the figures, identical reference signs will be used for identical or functionally equivalent features.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the following description, reference is made to the accompanying drawings, which form part of the disclosure, and in which are shown, by way of illustration, specific aspects in which the present invention may be placed. It will be appreciated that the invention may be placed in other aspects and that structural or logical changes may be made without departing from the scope of the invention. The following detailed description, therefore, is not to be taken in a limiting sense, as the scope of the invention is defined by the appended claims.

For instance, it will be appreciated that a disclosure in connection with a described method will generally also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if a specific method step is described, a corresponding device may include a unit to perform the described method step, even if such unit is not explicitly described or illustrated in the figures.

Moreover, in the following detailed description as well as in the claims, embodiments with functional blocks or processing units are described, which are connected with each other or exchange signals. It will be appreciated that the invention also covers embodiments which include additional functional blocks or processing units that are arranged between the functional blocks or processing units of the embodiments described below. Finally, it is understood that the features of the various exemplary aspects described herein may be combined with each other, unless specifically noted otherwise.

Figure 3 shows a schematic diagram illustrating a software defined network or system 100 comprising a controller 1 10 and a data packet forwarding device in the form of a switch 120a according to an embodiment. As will be appreciated, the switch 120a is a

representative of a plurality of switches 120a-c within the software defined network 100.

The SDN controller 1 10 shown in figure 3 is configured to control the forwarding of data packets, in particular control data packets, within the software defined network 100. As already mentioned above, the software defined network 100 can comprise in addition to the switch 120a a plurality of additional switches, such as the switches 120b and 120c shown in figures 4 and 5. Each of these switches 120a-c is configured to forward data packets, in particular control data packets, on the basis of a set of data packet forwarding rules within the software defined network 100.

The SDN controller 1 10 can be connected with each switch 120a-c via a plurality of transmission control protocol (TCP) control connections. In the embodiment shown in figure 3, two TCP sockets 1 18, 1 19 of the SDN controller 1 10 are connected via the TCP control connections 138, 139 with two TCP sockets 128, 129 of the switch 120a.

The SDN controller 1 10 comprises a first path manager submodule PM1 1 13 and a second path manager PM2 1 17. In an embodiment, the first path manager PM1 1 13 can be implemented in the transport layer of a TCP stack of the SDN controller 1 10, in particular as a part of a Multipath TCP kernel of the SDN controller 1 10. In an

embodiment, the second path manager PM2 1 17 can be implemented in the application plane of the software defined network 100, as illustrated in figure 3. Alternatively, the second path manager PM2 1 17 can be implemented as a software module of the SDN controller 1 10.

The first path manager PM1 1 13 is configured to establish in response to a request from one of the switches 120a-c a TCP control connection between the SDN controller 1 10 and the respective switch 120a-c. Generally, this TCP control connection can be an additional TCP control connection to one or more already existing TCP control connections between the SDN controller 1 10 and the respective switch 120a-c. For instance, in the embodiment shown in figure 3, the TCP control connection "TCP1 " 138 can be an already existing TPC control connection between the SDN controller 1 10 and the switch 120a and the first path manager PM1 1 13 of the SDN controller 1 10 can be configured to establish in response to a request from the switch 120a the additional TCP control connection "TCP2" 139 with the switch 120a. In an embodiment, establishing the additional TCP control connection "TCP2" 139 with the switch 120a can involve an exchange of control data between the first path manager PM1 1 13 of the SDN controller 1 10 and the switch 120a.

In the embodiment shown in figure 3, the first path manager PM1 1 13 of the SDN controller 1 10 is configured to inform the second path manager PM2 1 17 of the SDN controller 1 10 about the additional TCP control connection 139 between the SDN controller 1 10 the switch 120a. In response to being informed by the first path manager submodule PM1 1 13 about the new TCP connection 139 with the switch 120a, the second path manager PM2 1 17 of the SDN controller 1 10 is configured (i) to determine a control data packet path for the new TCP control connection 139 between the SDN controller 1 10 and the switch 120a and (ii) to provide a respective set of data packet forwarding rules to each switch of the plurality of switches 120a-c located along the control data packet path for the new TCP control connection 139. The sets of data packet forwarding rules are chosen by the second path manager PM2 1 17 of the SDN controller 1 10 such that these sets define for each TCP control connection 138, 139 between the SDN controller 1 10 and the switch 120a a unique control data packet path between the SDN controller 1 10 and the switch 120a.

In the embodiment shown in figure 3, the SDN controller 1 10 further comprises a scheduler SCH 1 15. The first path manager PM1 1 13 of the SDN controller 1 10 is configured to inform the scheduler SCH 1 15 about the new TCP control connection 139 between the SDN controller 1 10 and the switch 120a, once the new TCP control connection 139 with the switch 120a has been established. The scheduler SCH 1 15, in turn, is configured to allocate control data packets to the existing TCP control connections 138, 139 between the SDN controller 1 10 and the switch 120a for data packet

transmission. In an embodiment, the scheduler SCH 1 15 is configured to allocate control data packets to more than one TCP control connections of the plurality of TCP control connections 138, 139 of the SDN controller 1 10 for data packet transmission. In an embodiment, the scheduler SCH 1 15 is configured to determine the number of TCP control connections between the SDN controller 1 10 and the switch 120a, to which control data packets are to be allocated, on the basis of a message type associated with the control data packets. Message types could be, for instance, "high priority message" and "low priority message". Thus, in an embodiment, the scheduler SCH 1 15 can be configured to assign the control data packets of control messages of the type "high priority message" to more TCP control connections than control data packets of control messages of the type "low priority message".

In an embodiment, the first path manager 1 13 of the SDN controller 1 10 is configured to dynamically adjust the number of TCP connections 138, 139 between the SDN controller 1 10 and the switch 120a by keeping the number of TCP connections 138, 139 above a lower threshold. In an embodiment, the second path manager 1 17 is configured to determine the lower threshold for the number of TCP connections 138, 139 between the SDN controller 1 10 and the switch 120a on the basis of a status of the software defined network 100.

As already mentioned above, the switch 120a is configured to forward data packets, in particular control data packets, within the software defined network 100 on the basis of a set of data packet forwarding rules provided by the second path manager PM2 1 17 of the SDN controller 1 10. The switch 120a comprises a path manager PM1 123 configured to dynamically adjust the number of TCP control connections 138, 139 between the switch 120a and the SDN controller 1 10. In an embodiment, the path manager PM1 123 of the switch 120a is implemented in the transport layer. In the embodiment shown in figure 3, the switch 120a further comprises an agent 127 implemented on top of the transport layer. The agent 127 of the switch 120a can be configured to receive and implement the data packet forwarding rules provided by the SDN controller 1 10. In the embodiment shown in figure 3, the switch 120a further comprises a scheduler SCH 125 configured to allocate control data packets to the plurality of TCP control connections 138, 139 between the switch 120a and the SDN controller 1 10.

In an embodiment, the path manager PM1 123 of the switch 120a is configured to assign different TCP source ports 128, 129 to the plurality of TCP control connections 138, 139 between the switch 120a and the SDN controller 1 10.

In an embodiment, the path manager PM1 123 of the switch 120a is configured to dynamically adjust the number of TCP control connections 138, 139 between the switch 120a and the SDN controller 1 10 by keeping the number of TCP control connections 138, 139 between the switch 120a and the SDN controller 1 10 above a lower threshold. Maintaining a minimum number of TCP control connections 138, 139 allows ensuring a minimum "quality of service". In an embodiment, each switch 120a-c can have a switch- specific lower predefined threshold. In an embodiment, the lower threshold for each switch 120a-c can be determined by the second path manager PM2 1 17 of the SDN controller 1 10. In an embodiment, the lower threshold is more than one TCP control connection. In an embodiment, the path manager PM1 123 of the switch 120a is configured to adjust the lower threshold for the number of TCP control connections 138, 139 with the SDN controller 1 10 on the basis of a status of the software defined network 100, such as the status of its established TCP control connections with the SDN controller 1 10. For instance, the path manager PM1 123 of the switch 120a can be configured to increase the lower threshold for the number of TCP control connections 138, 139 with the SDN controller 1 10 in case of unstable network conditions.

As will be appreciated, the path managers and schedulers described above can be considered as an extension (herein referred to as multiport MPTCP) of the conventional path manager and scheduler defined in the MPTCP standard. In the embodiment shown in figure 3, the first path manager 1 13 and the scheduler 1 15 are part of a multiport MPTCP module 1 1 1 of the SDN controller 1 10 and the path manager 123 and the scheduler 125 are part of a multiport MPTCP module 121 of the switch 120a. As already described above, the path managers can guarantee path diversity between the switches 120a-c and the SDN controller 1 10, which MPTCP can exploit, whereas the schedulers improve the reliability of the control plane and reduce the latency in case of link failure by introducing traffic redundancy. In the exemplary scenario shown in figure 4, the software defined network 100 contains three switches S1 -S3 120a-c, which are implemented as OF switches S1 -S3 120a-c, as well as the SDN controller 1 10.

The switch S2 120a is connected to the switch S1 120b through physical port "portl " and to the switch S3 120c through physical port "port2". In the exemplary scenario shown in figure 4 the switch S2 120a is about to establish its connection to the SDN controller 1 10, whereas the switches S1 120b and S3 120c have already established their respective control channels to the SND controller 1 10. In accordance with, for instance the OpenFlow Switch Specification, the switch S2 120a can have an IP configuration including a local IP address (IP_S2) and knows the IP address and the TCP port of the SDN controller 1 10 (IP_C, tcpdportc), to which it can connect. In an embodiment, the path manager PM1 123 of the switch 123a can be based on the corresponding path manager of the MPTCP standard. The path manager of MPTCP can be configured in "ndiffports" mode so that it creates a plurality of TCP connections, i.e. N TCP connections, across the same pair of IP-addresses, modifying the source-port. The source port number can be selected randomly. Moreover, MPTCP creates a second connection if the first one is already established and so on.

The path manager PM1 123 of the switch 120a, which can be considered to be an extension of the conventional path manager implemented as part of MPTCP, is configured to adaptively change the value of N based on the condition of the established TCP connections, e.g., it may use larger values of N for dynamic settings. For example, if the path manager PM1 123 of the switch 120a detects that the established TCP connections with the SDN controller 1 10 are not very stable and suffer from high loss rate, the path manager PM1 123 of the switch 120a can be configured to increase N by a certain amount, e.g. by one, to increase the level of reliability.

By OF standard, this is the switch that triggers the establishment of its connection to the controller. An embodiment follows the same approach, so that this is PM1 at the switch that is responsible to decide the value of N and to establish new connections whenever necessary. PM1 at the controller 1 10 is responsible to inform PM2 whenever a new connection request is received from the switch 120a and track the state of each connection.

As already described above, in an embodiment, the path manager PM1 123 of the switch 120a is configured to establish a new TCP control connection if the number of established TCP control connections is below a lower threshold. This could happen in three cases: i) at the beginning where the number of established connections is still lower than the lower threshold, ii) when a link is failed, as the number of established TCP control connections between the switch 120a and the controller 1 10 turns below the lower threshold, and/or iii) when the path manager PM1 123 of the switch 120a increases the value of the lower threshold to adapt to changing network conditions.

In the exemplary scenario of figure 4, the first TCP control connection established by the switch S2 120a is identified by IPs2, tcpsporti , IPc, tcpdportc and the second TCP control connection established by the switch S2 120a is identified by IPs2, tcpsport₂, IPc, tcpdportc, where tcpsporti and tcpsport₂ are random source ports, which might not be known to the SDN controller 1 10.

As already explained above, in an embodiment the second path manager PM2 1 17 is an SDN application at the top of the software hierarchy of the SDN controller 1 10 (or alternatively a module of the SDN controller 1 10) and is configured to set appropriate data packet forwarding rules at the plurality of switches S1 , S2, and S3 120a-c, such that each of the connections established by the path manager 123 of the switch S2 120a follow different, i.e. unique, paths between the switch S2 120a and the SDN controller 1 10.

In an embodiment, the switches S1 -S3 120a-c can be configured as Open Flow switches. In this case, each switch S1 -S3 120a-c generally cannot distinguish between a control packet and a data packet, unless it is the source or the destination of the control packet. Consequently, an OF switch will not distinguish between relaying control traffic and data traffic and will use its forwarding rules (specified by second path manager PM2 1 17 of the SDN controller 1 10) to forward all data packet flows. In an embodiment, each switch S1 - S3 120a-c has a TCP/IP stack for the TCP connections to the SDN controller 1 10, which in comparison to a conventional TCP/IP stack can be configured for multiport MPTCP, as defined by embodiments of the invention.

In the following, it will be described how in an embodiment two TCP connections are established as well as the set of forwarding rules implemented at the switches S1 -S3 120a-c. In a first stage, a TCP-SYN packet sent by the switch S2 120a, with tcpsporti as the source port, will be send over one of the physical ports connected to one of the neighboring switches (the switch S2 120a will send an ARP request, as part of the TCP establishment process, to identify which physical port it can use to transmit its TCP-SYN packet).

As the relay switch (e.g. switch S1 120b) cannot distinguish between data and control traffic, it requests the SDN controller 1 10 what to do with this packet.

The SDN controller 1 10 (more specifically its first path manager PM1 1 13) sends this message to the second path manager PM2 1 17, and in response thereto the second pat manager PM2 1 17 defines the forwarding rules at the relay switch S1 120b. The SDN controller 1 10 replies with a TCP-SYN-ACK in response to the packet from the switch S2 120a after the forwarding rules have been set at the switch S1 120b. Thus, the first TCP connection between the switch S2 120a and the SDN controller 1 10 is established so that the second path manager PM2 1 17 of the SDN controller 1 10 can implement the following forwarding rules at the switch S2 120a:

(i) If (source-IP = IP_S2 & source-port = tcpsporti) and (destination-IP = IP_C & destination-port = tcpdport_c) then forward the packet over portl (e.g. to switch 120b S1 ); or

(ii) If (source-IP = IP_s2) and (destination-IP = IP_C & destination-port = tcpdportc) then forward the packet over port2 (e.g. to switch S3 120c).

On the basis of this set of forwarding rules, the switch S2 120a will forward its control data packets that have a source port different from tcpsporti over port2 to the switch S3 120c.

Then the path manager PM1 123 at the switch S2 120a creates the second TCP connection, by sending a TCP-SYN packet with tcpsport₂ as the source port over port2 to the switch S3 120c.

When the switch S3 120c receives the packet, the same procedure as described above in the context of the switch S2 120b will be repeated in the context of the switch S3 120c for creating the second TCP connection. Further TCP connections can be established in the same manner.

Some of the steps described above may occur in a different order. For instance, the switch S2 120a may send the TCP-SYN packet for the new TCP connection before the SDN controller 1 10 can implement appropriate forwarding rules at the switch S2 120a. In this case, the connection can be initially established over the path "switch S2"-"switch S1 "- "controller" and then will be redirected over the second path "switch S2"-"switch S3"- "controller" after the forwarding rules have been implement at the switch S2 120a.

In another embodiment, the switches 120a-c are configured as hybrid switches, i.e. as switches having traditional capabilities (such as RTSP and neighbor discovery) as well as OF capabilities (e.g. performing forwarding rules specified by the controller). In an embodiment, each of the hybrid switches 120a-c is configured to reach another switch 120a-c or the controller 1 10 by running the L2/L3 mechanisms known from the prior art. In an embodiment, the switches 120a-c are implemented as Open vSwitches (OVS). Such switches are configured to distinguish between control and data traffic and to apply different forwarding rules for control traffic than for data traffic. Moreover, these types of switches try to detect relayed control traffic, which is generally not the case with OF only switches.

In the following, it will be described how in an embodiment based on hybrid switches two TCP connections are established as well as how the sets of forwarding rules are implemented at the hybrid switches 120a-c.

In a first stage, a TCP-SYN packet sent by the switch S2 120a with tcpsporti will be forwarded over one of the physical ports (e.g. over the physical port connected to the switch S1 120b) according to the forwarding rules for control data packets.

When the switch S1 120b receives the TCP-SYN packet from the switch S2 120a addressed to the SDN controller 1 10, the switch S1 120b forwards the packet to the SDN controller 1 10 using its control data packet forwarding rules. Once the SDN controller 1 10 receives the packet originating from the switch S2 120a, it replies with a SYN-ACK and the first path manager PM1 1 13 informs the second path manager PM2 1 17 about the creation of this TCP connection. Thus, the first TCP connection is established. The SDN controller 1 10 is now connected to the switch S2 120a, and hence the second path manager PM2 1 17 can set the following forwarding rules for the switch S2 120a:

(i) If (source-IP = IP_S2 & source-port = tcpsporti) and (destination-IP = IP_C & destination-port = tcpdport_c) then forward the packet over portl (e.g. to switch S1 120b);

(ii) If source-IP = IP_S2 and (destination-IP = IP_C & destination-port = tcpdportc) then forward the packet over port2 (e.g. to switch S3 120c). In an embodiment, the second path manager PM2 1 17 is further configured to execute the following rules: (i) Set "in advance" the network forwarding rules at the switch S3 120c, to determine how to forward the second connection request at the switch S3 120c; and (ii) Request the switch S3 120c to send a packet-in event upon reception of a packet with matching IP_S2, IPc, and tcpdportc. By doing this, the SDN controller 1 10 is informed about the creation of the second TCP connection and the value of tcpsport₂. This information can be used for setting up the forwarding rules at the switch S2 120a (see step above). In an embodiment, the controller 1 10 can be configured to remove this forwarding rule from the switch S3 120c in response to being informed about the creation of the second TCP connection.

In a further stage, the path manager PM1 123 of the switch S2 120a sends a TCP-SYN packet for the second TCP connection with tcpsport₂ as the source port. The switch S2 120a sends the packet over port2 to the switch S3 120c.

In response to receiving the packet, the switch S3 120c sends the packet following the rule that has been set in advance by the second path manager PM2 1 17 and moreover creates a packet-in event, which will be forwarded to the second path manager PM2 1 17 by the SDN controller 1 10. Thus, the second TCP connection is established.

In order to create one or more additional TCP connections at least some of the steps described above can be repeated. If the final step occurs before the previous step, the second TCP connection would be initially established over the path "switch S2"-"switch S1 "-"controller". In an embodiment, the second TCP connection can be redirected over the path "switch S2"-"switch S3"- "controller", once the forwarding rules have been implemented at the switch S2 120a and the switch S3 120c by executing the respective steps above.

As will be appreciated, in the scenarios described above and shown in figure 4 there is one intermediate switch or relay between the switch S2 120a and the SDN controller 1 10, namely the switch S1 120b and the switch S3 120c, respectively. In the following these scenarios will be generalized to scenarios with more than one intermediate relay, i.e. to multi-relay scenarios. If there is more than one intermediate switch on a path, e.g. the path "switch S2"-"switch S1 "-"switch S4"-"controller" instead of the previously described path "switch S2"-"switch S1 "-"controller", the TCP-SYN packet will be received by the switch S4 after being processed by the switch S1 . In the case of hybrid switches, the packet would be forwarded to the SDN controller 1 10 using its control data packet forwarding rules. In the case of OF-only switches, an equivalent procedure of to the one described above will be executed: the switch S4 generates a packet-in event to the SDN controller 1 10, requesting for a specific action, and the SDN controller 1 10 sets the forwarding rules at the switch S4. This process will be repeated until all intermediate switches are configured accordingly and until TCP-SYN is received by the SDN controller 1 10, where the procedure can proceed as described above for the case of a single intermediate switch.

As already described above, the schedulers 1 15, 125 can be considered as advantageous extensions of the schedulers implemented in the MPTCP standard. In an embodiment, the schedulers 1 15, 125 are configured to transmit redundant packets over established TCP connections, improving recovery time after a failure. In an embodiment, the scheduler 1 15 of the SDN controller 1 10 and the scheduler 125 of the switch S2 120a are configured to operate independently from each other. In other words, each scheduler can decide how to schedule its data packet over the established TCP connections. In the example of figure 5, the SDN controller 1 10 transmits the same packets, e.g. the packets P1 , P2, and P3 shown in figure 5, over the established paths (e.g. the first path "controller"-"switch S3"-"switch S2" and the second path "controller"-"switch S1 "-"switch S2"). If the link "switch S1 "-"switch S2" fails, the SDN controller 1 10 does not need to retransmit the packets P1 , P2, P3 again as copies of these packets have been already sent over the other path. This will significantly reduce the number of retransmissions necessary to recover from a failure and reduce the latency.

In an embodiment, different QoS (quality of service) classes for different types of messages exchanged between the controller 1 10 and the switches 120a-c can be used for deciding the level of redundancy for each of these QoS classes. In an embodiment, packets that belong to high priority classes can be duplicated over more connections than those that belong to lower priority classes, as already described above.

Figure 6 shows a schematic diagram illustrating a method 600 of operating the controller 1 10 of the software-defined network 100 according to an embodiment. The method 600 comprises the steps of: establishing 601 in response to a request from the switch S2 120a a TCP control connection 138, 139 between the controller 1 10 and the switch S2 120a; determining 603 a control data packet path for the TCP control connection 138, 139 between the SDN controller 1 10 and the switch S2 120a; and providing 607 a respective set of data packet forwarding rules to each switch 120a-c located along the control data packet path for the TCP control connection 138, 139 between the SDN controller 1 10 and the switch S2 120a, wherein the sets of data packet forwarding rules define for each TCP control connection 138, 139 with each switch 120a-c a unique control data packet path between the SDN controller 1 10 and the respective switch 120a-c. Figure 7 shows a schematic diagram illustrating a method 700 of operating the switch S2 120a of the software-defined network 100 according to an embodiment. The method 700 comprises the step 701 of dynamically adjusting the number of TCP control connections 138, 139 between the switch 120a and the SDN controller 1 10 configured to control the forwarding of control data packets within the software defined network 100.

Embodiments of the invention provide, in particular, for the following advantages.

Embodiments of the invention provide an improved SDN control plane resiliency, as the negative effects of a link failure are mitigated. Embodiments of the invention reduce the latency, as a more robust and lower latency communication for control plane traffic is provided. Embodiments of the invention can result in a cleaner and simpler SDN design, as control applications can be written with less link failure detection routines.

Embodiments of the invention can be easily implemented in the general framework of MPTCP so that there is no need to change the infrastructure or to assign a separate channel for the control plane messages.

While a particular feature or aspect of the disclosure may have been disclosed with respect to only one of several implementations or embodiments, such feature or aspect may be combined with one or more other features or aspects of the other implementations or embodiments as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms "include", "have", "with", or other variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprise". Also, the terms "exemplary", "for example" and "e.g." are merely meant as an example, rather than the best or optimal. The terms "coupled" and "connected", along with derivatives may have been used. It should be understood that these terms may have been used to indicate that two elements cooperate or interact with each other regardless whether they are in direct physical or electrical contact, or they are not in direct contact with each other.

Although specific aspects have been illustrated and described herein, it will be

appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific aspects shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the specific aspects discussed herein.

Although the elements in the following claims are recited in a particular sequence with corresponding labeling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence.

Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art readily recognize that there are numerous applications of the invention beyond those described herein. While the present invention has been described with reference to one or more particular embodiments, those skilled in the art recognize that many changes may be made thereto without departing from the scope of the present invention. It is therefore to be understood that within the scope of the appended claims and their equivalents, the invention may be practiced otherwise than as specifically described herein.

Claims

1 . A controller (1 10) configured to control forwarding of data packets within a software defined network (100), wherein the controller (1 10) can be connected with a data packet forwarding unit (120a-c) via at least two transmission control protocol, TCP, connections (138, 139), wherein the controller (1 10) comprises: a first path manager (1 13) and a second path manager (1 17), wherein the first path manager (1 13) is configured in response to a request from the data packet forwarding unit (120a-c) to establish a TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) and to inform the second path manager (1 17) about the TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c), and wherein the second path manager (1 17) is configured to determine a data packet path for the TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) and to provide a respective set of data packet forwarding rules to each data packet forwarding unit (120a-c) located along the data packet path for the TCP connection (138, 139), wherein the sets of data packet forwarding rules define for each TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) a unique data packet path between the controller (1 10) and the data packet forwarding unit (120a-c).

2. The controller (1 10) of claim 1 , wherein the first path manager (1 13) is

implemented in the transport layer of a TCP stack of the controller (1 10) and/or the second path manager (1 17) is implemented in an application plane of the software defined network (100).

3. The controller (1 10) of claim 1 or 2, wherein the first path manager (1 13) is implemented as a part of a Multipath TCP kernel of the controller (1 10).

4. The controller (1 10) of any one of the preceding claims, wherein the controller (1 10) further comprises a scheduler (1 15), wherein the first path manager (1 13) is further configured to inform the scheduler (1 15) about the TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) and wherein the scheduler (1 15) is configured to allocate data packets to the at least two TCP connections (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) for data packets transmission.

5. The controller (1 10) of claim 4, wherein the scheduler (1 15) is further configured to allocate at least one data packet to a first TCP connection and at least one additional TCP connection of at least two TCP connections (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) for data packets transmission.

6. The controller (1 10) of claim 5, wherein the scheduler (1 15) is further configured to determine the number of additional TCP connections between the controller (1 10) and the data packet forwarding unit (120a-c) on the basis of a message type associated with the data packets.

7. The controller (1 10) of any one of the preceding claims, wherein the first path manager (1 13) is configured to dynamically adjust the number of TCP connections (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) by keeping the number of TCP connections (138, 139) above a lower threshold.

8. The controller (1 10) of claim 7, wherein the second path manager (1 17) is configured to determine the lower threshold for the number of TCP connections (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) on the basis of a status of the software defined network (100).

9. A data packet forwarding unit (120a-c) configured to forward data packets within a software defined network (100) on the basis of a set of data packet forwarding rules, wherein the data packet forwarding unit (120a-c) comprises: a path manager (123) configured to dynamically adjust the number of at least two transmission control protocol, TCP, connections (138, 139) between the data packet forwarding unit (120a-c) and a controller (1 10) configured to control the forwarding of data packets within the software defined network (100).

10. The data packet forwarding unit (120a-c) of claim 9, wherein the path manager (123) is configured to assign different TCP source ports (128, 129) to the at least two TCP connections (138, 139) between the data packet forwarding unit (120a-c) and the controller (1 10).

1 1 . The data packet forwarding unit (120a-c) of claim 9 or 10, wherein the path manager (123) is configured to dynamically adjust the number of TCP connections (138, 139) between the data packet forwarding unit (120a-c) and the controller (1 10) by keeping the number of TCP connections (138, 139) between the data packet forwarding unit (120a-c) and the controller (1 10) above a lower threshold.

12. The data packet forwarding unit (120a-c) of any one of claims 9 to 1 1 , wherein the path manager (123) is configured to adjust the lower threshold for the number of TCP connections (138, 139) between the data packet forwarding unit (120a-c) and the controller (1 10) on the basis of the status of its established connections to the controller (1 10).

13. The data packet forwarding unit (120a-c) of claim 12, wherein the path manager (123) is configured to receive the lower threshold for the number of TCP connections (138, 139) between the data packet forwarding unit (120a-c) and the controller (1 10) from the controller (1 10).

14. The data packet forwarding unit (120a-c) of any one of claims 9 to 13, wherein the data packet forwarding unit (120a-c) further comprises a scheduler (125) configured to allocate data packets to the plurality of TCP connections (138, 139) between the data packet forwarding unit (120a-c) and the controller (1 10) for data packets transmission.

15. A SDN system (100) comprising a controller (1 10) according to any one of claims 1 to 8 and at least two data packet forwarding units (120a-c) according to any one of claims 9 to 14.

16. A method (600) of operating a controller (1 10) configured to control forwarding of data packets within a software defined network (100), wherein the controller (1 10) can be connected with a data packet forwarding unit (120a-c) via at least two transmission control protocol, TCP, connections (138, 139), wherein the method (600) comprises the steps of: establishing (601 ) in response to a request from the data packet forwarding unit (120a-c) a TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c); determining (603) a data packet path for the TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c); and providing (605) a respective set of data packet forwarding rules to each data packet forwarding unit (120a-c) located along the data packet path for the TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c), wherein the sets of data packet forwarding rules define for each TCP connection (138, 139) between the controller (1 10) and the data packet forwarding unit (120a-c) a unique data packet path between the controller (1 10) and the data packet forwarding unit (120a-c).

17. A method (700) of operating a data packet forwarding unit (120a-c) configured to forward data packets within a software defined network (100) on the basis of a set of data packet forwarding rules, wherein the method (700) comprises: dynamically (701 ) adjusting the number of at least two transmission control protocol, TCP, connections (138, 139) between the data packet forwarding unit (120a-c) and a controller (1 10) configured to control the forwarding of data packets within the software defined network (100).

18. A computer program comprising program code for performing the method (600) of claim 16 or the method (700) of claim 17 when executed on a computer.