Joint Switch Upgrade and Controller Deployment in Hybrid Software-Defined Networks

TL;DR

This paper addresses the joint deployment of SDN switches and controllers in hybrid networks, optimizing for flow control capacity and delay, using a formulated NP-hard problem and proposing efficient solutions validated by simulations.

Contribution

It introduces a novel joint deployment optimization model for hybrid SDNs, considering both switch and controller placement under budget constraints, with tailored algorithms for different network sizes.

Findings

Heuristic algorithm manages many flows with few controllers.

Proposed techniques accelerate optimization for small networks.

Simulation shows high flow management efficiency with low delay.

Abstract

To improve traffic management ability, Internet Service Providers (ISPs) are gradually upgrading legacy network devices to programmable devices that support Software-Defined Networking (SDN). The coexistence of legacy and SDN devices gives rise to a hybrid SDN. Existing hybrid SDNs do not consider the potential performance issues introduced by a centralized SDN controller: flow requests processed by a highly loaded controller may experience long tail processing delay; inappropriate multi-controller deployment could increase the propagation delay of flow requests. In this paper, we propose to jointly consider the deployment of SDN switches and their controllers for hybrid SDNs. We formulate the joint problem as an optimization problem that maximizes the number of flows that can be controlled and managed by the SDN and minimizes the propagation delay of flow requests between SDN controllers and switches under a given upgrade budget constraint. We show this problem is NP-hard. To efficiently solve the problem, we propose some techniques (e.g., strengthening the constraints and adding additional valid inequalities) to accelerate the global optimization solver for solving the problem for small networks and an efficient heuristic algorithm for solving it for large networks. The simulation results from real network topologies illustrate the effectiveness of the proposed techniques and show that our proposed heuristic algorithm uses a small number of controllers to manage a high amount of flows with good performance.

Tables

Table 1. Table I: Notations

Notation	Meaning
$N$	the number of switches
$M$	the upgrade budget
$A$	the processing capacity of a controller
$i$	the index of a switch, $i\in [1,N]$
$j$	the index of a controller, $j\in [1,N]$
$\gamma$	the cost ratio of an SDN switch to a controller
$𝒲$	the set of weights, $𝒲=\left\{\{w_{11},\dots ,w_{1j},\dots ,w_{1N}\},\dots ,\{w_{i1},\dots ,w_{ij},\dots ,w_{iN}\},\dots ,\{w_{N1},\dots ,w_{Nj},\dots ,w_{NN}\},i,j\in [1,N]\right\}$
$ℛ$	the set of the number of flows in each switch, $ℛ=\left\{R_i,i\in [1,N]\right\}$
$𝒳$	the set of updated switches, $𝒳=\left\{i\in [1,N]\right|x_i=1\}$
$𝒴$	the set of deployed controllers, $𝒴=\left\{j\in [1,N]\right|y_j=1\}$
$𝒵$	the set of the mapping relationship between upgraded switches and controllers, $𝒵=\left\{(i,j)\in [1,N]\times [1,N]\right|z_{ij}=1\}$

Table 2. Table II: Computational results of (a) original formulation ( P ), and (b) formulation ( P’ ).

Topology name	Topology info		Elapsed CPU time (seconds)
	# of nodes	# of links	(a)	(b)
Colt	153	185	2046.46	33.04
GtsCe	150	193	1365.47	89.17
Cogentco	197	245	3600.00	419.49
Condensed_west_europe	278	394	3600.00	576.93
Condensed	463	620	2721.63	1013.31

Equations

$$z_{ij}\le x_i,\text{leavevmode}\forall \text{leavevmode}i,\text{leavevmode}\forall \text{leavevmode}j,$$

$$z_{ij}\le y_j,\text{leavevmode}\forall \text{leavevmode}i,\text{leavevmode}\forall \text{leavevmode}j.$$

$$x_i=\sum _{j=1}^N{z}_{ij},\text{leavevmode}\forall \text{leavevmode}i.$$

$$y_j\le \sum _{i=1}^N{z}_{ij},\text{leavevmode}\forall \text{leavevmode}j.$$

$$\sum _{i=1}^N(R_i\ast x_i\ast z_{ij})\le A,\text{leavevmode}\forall \text{leavevmode}j,$$

$$\sum _{i=1}^N(R_i\ast z_{ij})\le A,\text{leavevmode}\forall \text{leavevmode}j.$$

$$\gamma \ast \sum _{i=1}^N{x}_i+\sum _{j=1}^N{y}_j\le M.$$

$$ob{j}_1=\sum _{i=1}^N(R_i\ast x_i).$$

$$ob{j}_2=\sum _{i=1}^N\sum _{j=1}^N(D_{ij}\ast z_{ij}).$$

$$F^{\ast }=\underset{x,y,z}{\max }$$

$$(\text{ref}controller)(\text{ref}con1)(\text{ref}con2)(\text{ref}con3)(\text{ref}con4),$$

$$x_i,y_j,z_{ij}\in \{0,1\},\text{leavevmode}\forall \text{leavevmode}i,\text{leavevmode}\forall \text{leavevmode}j.$$

$$\underset{x,y,z}{\min }$$

$$F^{\ast }=\sum _{i=1}^N{R}_i{x}_i,(\text{ref}controller)(\text{ref}con1)(\text{ref}con2)(\text{ref}con3)(\text{ref}con4),$$

$$x_i,y_j,z_{ij}\in \{0,1\},\text{leavevmode}\forall \text{leavevmode}i,\text{leavevmode}\forall \text{leavevmode}j.$$

$$\underset{x,y,z}{\max }$$

$$(\text{ref}controller)(\text{ref}con1)(\text{ref}con2)(\text{ref}con3)(\text{ref}con4),$$

$$x_i,y_j,z_{ij}\in \{0,1\},\text{leavevmode}\forall \text{leavevmode}i,\text{leavevmode}\forall \text{leavevmode}j,$$

$$0<\lambda <\frac{d}{{\sum }_{i=1}^N{\text{max}}_{1\le j\le N}\{D_{ij}\}},$$

$$\sum _{i=1}^N{R}_i{\bar{x}}_i-\sum _{i=1}^N{R}_i{x}_i^{\ast }\ge d.$$

$$\lambda \sum _{i=1}^N\sum _{j=1}^N{D}_{ij}{\bar{z}}_{ij}\le \lambda \sum _{i=1}^N{\text{max}}_{1\le j\le N}\{D_{ij}\}{\bar{z}}_{ij}$$

$$\sum _{i=1}^N{R}_i{\bar{x}}_i-\lambda \sum _{i=1}^N\sum _{j=1}^N{D}_{ij}{\bar{z}}_{ij}>\sum _{i=1}^N{R}_i{x}_i^{\ast }+d-d$$

$$\underset{x,y,z}{\max }$$

$$\text{eqref}controller\text{eqref}con1\text{eqref}con2,$$

$$\sum _{i=1}^{3m}{a}_i{z}_{ij}\le B,1\le j\le N,$$

$$\sum _{i=1}^{3m}{x}_i+\sum _{j=1}^N{y}_j\le 4m,$$

$$x_i,y_j,z_{ij}\in \{0,1\},1\le i\le 3m,1\le j\le N.$$

$$\sum _{j=1}^N{\bar{y}}_j=m.$$

$$\sum _{i=1}^{3m}{a}_i{\bar{x}}_i$$

$$\sum _{i=1}^{3m}{a}_i{\bar{z}}_{ij}=B,1\le j\le m.$$

$$\sum _{i\in S_j}{a}_i=\sum _{i=1}^{3m}{a}_i{\bar{z}}_{ij}=B.$$

$${\mathcal{S}}_1\cup \cdots \cup {\mathcal{S}}_m=\{1,\dots ,3m\}.$$

$$\sum _{i=1}^N(R_i\ast z_{ij})\le A\ast y_j,\text{leavevmode}\forall \text{leavevmode}j.$$

$$\sum _{j=1}^N{z}_{ij}=1,\text{leavevmode}\forall \text{leavevmode}i,$$

$$\sum _{j=1}^N{y}_j\le M-\gamma N.$$

Full text

In this paper, we propose to jointly consider the deployment of SDN switches and their controllers for hybrid SDNs. We formulate the joint problem as an optimization problem that maximizes the number of flows that can be controlled and managed by the SDN and minimizes the propagation delay of flow requests between SDN controllers and switches under a given upgrade budget constraint. We show this problem is NP-hard. To efficiently solve the problem, we propose some techniques (e.g., strengthening the constraints and adding additional valid inequalities) to accelerate the global optimization solver for solving the problem for small networks and an efficient heuristic algorithm for solving it for large networks. The simulation results from real network topologies illustrate the effectiveness of the proposed techniques and show that our proposed heuristic algorithm uses a small number of controllers to manage a high amount of flows with good performance.

I Introduction

Software-Defined Networking (SDN) has been widely studied and gradually adapted for campus networks [1], data center networks [2], Wide Area Networks (WANs) [3], enterprise networks [4], and Internet exchange points [5]. Due to the cost and operational considerations, SDN technology is usually deployed in an incremental fashion. In particular, at each time of network upgrade, only a set of selected legacy network devices (i.e., layer-3 routers and layer-2 switches) are upgraded to SDN switches. AT&T converted 34% of its network to SDN by the end of 2016 and virtualized 55% of its network to software by the end 2017. Its final goal is to reach 75% softwarization of its network by 2020 [6]. Therefore, the legacy network devices and SDN switches may coexist for a long time. In this paper, we will refer to such a network as a hybrid SDN.

A WAN usually consists of many network devices at geo-distributed locations. A straightforward method to upgrade legacy network devices in WANs to SDN switches is based on the locations of network devices, for example, upgrade a part of WAN with network devices in proximity. The partial upgraded network can enjoy the benefit of SDN, but the performance improvement of the entire network is limited. An efficient solution for network providers is to spread the benefit of upgraded SDNs in the entire network. Based on this consideration, existing studies proposed to upgrade legacy network devices in WANs to SDN switches for different reasons or with different motivations, such as traffic engineering [7][8], flexible routing [9], link failure recovery [10], power saving [11][12], and safe update [13]. Essentially, the benefit of SDN is to flexibly control flows. Once a flow traverses an SDN switch, its forwarding path can be flexibly controlled. We call such traffic the programmable traffic. The selection of switches to be upgraded to SDN switches has a great impact on the network’s programmable performance. In a WAN, switches tend to have quite different numbers of flows. If we randomly select some of them to upgrade, we may not be able to achieve our objective to maximize the number of programmable flows. Some studies aim to maximize the amount of programmable traffic under the constraint of a given upgrade budget [14][15]. However, the impact of SDN controller on the network upgrade is not taken into consideration in these works.

The control plane of SDN has evolved from one single controller to multiple controllers to circumvent the limited computational resource of a controller server and avoid single point of failure. For a large wide-area SDN, multiple distributed controllers are physically deployed at different locations to achieve the function of a logically centralized control plane, and the controllers synchronize with each other to guarantee the consistency of the entire network [16][17]. To avoid the single-point-of-failure problem, backup controllers maybe deployed [18][19]. If one controller instance crashes, other active instances will still work without service interruption. Popular SDN controllers (e.g., ONOS and OpenDayLight) usually use three controllers to provide resilient service at one location, and the three controllers communicate with each other (e.g., using Raft [20]) to guarantee the network state consistency [21][22].

Deploying multiple controllers in a hybrid SDN should take the following two factors into account. First, controllers should be able to process flow requests from the upgraded SDN switches in a timely manner. If a controller is overloaded, the requests handled by it may suffer from long-tail latency [23], which might significantly degrade the network performance [24]. Second, the deployment locations of controllers affect the propagation delay of flow requests and network state pulling because the propagation delay in WANs is usually a significant part of the total delay [25][26]. Existing works [7][8][14][15] for the network upgrade did not consider the above factors, which may lead to some undesirable performance degradations. We detail the two factors in Section II.

In this paper, we consider the above two factors and propose two objectives: (1) maximizing the number of flows managed by SDN and (2) minimizing the propagation delay of flow requests from SDN switches with an upgrade budget constraint. The first objective aims to control as many flows as possible by upgrading legacy devices to SDN switches, while the second objective aims to reduce the propagation delay between the SDN controllers and switches by effectively deploying a few controllers near SDN switches. Our problem is to find the locations of upgraded switches, the locations of deployed controllers, and the mappings between the controllers and the upgraded switches (i.e., which controllers control which upgraded SDN switches) to maximize the number of controlled programmable flows and at the same time minimize the propagation delay between the controllers and upgraded switches under individual controllers’ processing ability and upgrade budget constraints. We first formulate a two-stage optimization problem that optimizes one objective at each stage and then transform the two-stage problem into a one-stage problem to simplify the solution procedure. We prove that with a careful choice of the parameter the optimal solution of the one-stage formulation is also the optimal solution of the two-stage formulation.

It is worth noting that our work is different from the controller deployment in pure SDNs. In pure SDNs, all switches are SDN switches, and the controllers’ deployment only needs to consider two aspects: (1) the controllers’ location and number and (2) mapping between SDN switches and controllers. In hybrid SDNs, our problem needs to consider one more aspect: the location and number of the upgraded SDN switches. In our problem, the three aspects are related to each other, and our problem in hybrid SDNs is more complicated than the controllers’ deployment in pure SDNs.

To efficiently solve the problem, we analyze the problem’s structure and propose several solutions. For the problem in small networks, we accelerate the global optimization solver by proposing a new problem formulation. For the problem in large networks, to further improve the computational efficiency, we propose a heuristic algorithm named MapFirst, which first orders the (relaxed) mapping variables between controllers and upgraded switches according to their importance/weights (obtained by solving a linear program relaxation) and then sequentially determines the (binary) mapping variables based on their impacts on the objective function.

We conduct simulations using real network topologies from Topology Zoo [27]. The simulation results on multiple topologies verify the effectiveness and efficiency of the new problem formulation. We further compare MapFirst with optimal solutions and other heuristic algorithms, and the results show (1) MapFirst outperforms other heuristic algorithms by using a small number of controllers to facilitate a high amount of flows from upgraded SDN switches, and (2) compared to the optimal solution, MapFirst is able to achieve a comparable performance but enjoys a significantly low complexity.

The contributions of the paper are summarized as follows:

Novel problem formulation: We identify the impact of the control plane on the network upgrade and formulate an optimization problem to guarantee the performance of the hybrid SDN by jointly upgrading switches and deploying controllers. 2. 2.

Efficient solutions: We propose efficient exact and heuristic solutions to solve the problem for both small and large networks. Our simulation results (on real network topologies) demonstrate that our exact solution significantly accelerates the optimization solver, and our proposed MapFirst is able to return a high-quality solution with a significant less CPU time. 3. 3.

Theoretical analysis: We provide some analysis on the problem and the solutions. For the problem, we provide a rigorous NP-hardness proof and shed a useful insight that the problem (probably) does not admit constant-ratio approximation algorithms to only approximate the total delay in our problem. In addition, we also identify a special case of the problem which is strongly polynomial time solvable. For the proposed MapFirst, we analyze its worst-case complexity and prove that it is able to return the global solution of the problem if each controller can control at most one SDN switch.

The rest of this paper is organized as follows: Section II illustrates the motivation of the paper with some examples. Section III formulates the Joint Switch Upgrade and Controller Deployment (JSUCD) problem, and Section IV analyzes the parameter selection and the complexity of the problem. Section V introduces exact and heuristic solutions for the JSUCD problem. Section VI presents the simulation results and analysis. Section VII introduces the related works. Section VIII concludes the paper and presents our future work.

II An Example and Motivation

In this section, we use a motivation example in Fig. 1 to show how the network upgrade affects the performance of the hybrid SDN.

II-A Example background

Fig. 1(a) shows the network composition: the network has 6 legacy switches $s_{1}$ to $s_{6}$ deployed at six different locations with uneven interconnection. We assume that the number of flows in each switch is proportional to the number of its links, and the total number of flows on a link is normalized as 1. The number of normalized flows at the six switches are: $f_{s1}=2,f_{s2}=3,f_{s3}=2,f_{s4}=5,f_{s5}=3,f_{s6}=3$. The normalized processing ability of each controller is $p_{c}=6$. The upgrade budget includes switch upgrade cost and controller deployment cost. In this example, the upgrade budget allows upgrading at most four legacy devices to SDN switches, and the cost of an SDN switch is three times of a controller. In other words, if we upgrade one less switch, we can deploy three more controllers at three locations111At a location, a controller is physically implemented by a controller instance cluster to prevent single-node-of-failure [18][19]. We can either use two instances or three instances for a cluster. However, the odd number accelerates the primary controller selection in the case of the controller failure, and the production networks usually use three instances [21][22]. In the rest of the paper, we use a controller to represent a controller cluster at a location since a cluster usually uses one controller to process requests, and the other two are just backup and thus do not process any requests.. We assume that one SDN switch can only be controlled by exactly one controller, and one controller can potentially control multiple SDN switches. Our problem is to find a feasible solution that contains a set of upgraded switches, a set of controllers, and the mappings between the upgraded switches and controllers to maximize the number of controlled programmable flows and at the same time minimize the delay between the controllers and upgraded switches under the constraints of the upgrade budget and individual controller’s processing ability.

II-B Impact of the network upgrade on the hybrid SDN

II-B1 Maximizing the benefit of SDN by selecting upgraded SDN switches

If a flow traverses one SDN switch, it is a programmable flow and we can enjoy the benefit of SDN by flexibly controlling the flow’s forwarding path. Thus, the benefit of SDN depends on the number of programmable flows. We use $A_{s}$ to denote the total number of programmable flows from the upgraded SDN switches. Our first goal is to maximize $A_{s}$ with a given switch upgrade budget. There are 20 switch combinations for selecting three switches from six switches to upgrade. Fig. 1(b) shows three switch selection combinations that control the largest number of flows $A_{s}=3+3+5=11$: ${red}=\{s_{2},s_{4},s_{6}\}$, ${blue}=\{s_{4},s_{5},s_{6}\}$, $green=\{s_{2},s_{4},s_{5}\}$.

II-B2 Guaranteeing the processing performance of flow requests by considering the processing ability of controllers

We use $blue$ switch selection in the following explanation. The $red$ and $green$ switch selections follow the similar explanation. We use $A_{c}$ to denote the total processing ability of the deployed controllers. Existing works show when a controller processes more requests than its normal processing load, the processing delay of the requests could be five times longer than the one under the normal load [23] [24]. To maintain the processing performance of flow requests, after a network upgrade, for the entire network, it is necessary to require $A_{s}\leq A_{c}$, and for controllers, each one should not process the number of flow requests larger than its normal processing ability. In Fig. 1(c), deploying one controller can either control the flows at switch $s_{4}$ or the flows at the other two switches, and thus deploying one controller is not enough. In Fig. 1(d), deploying one controller for each switch can satisfy the control requirement, but the controllers’ processing ability of such a deployment is much larger than the number of flows from SDN switches. The extra number of controllers could also bring extra overhead. If we deploy many controllers, the number of switches controlled by a controller would be small, and a controller’s control ability on the network would be reduced. Thus, after a network upgrade, we prefer to deploy a few controllers to satisfy the demand of SDN switches. In this example, we only need two controllers since $A_{s}<A_{c}=p_{c}*2=12,f_{s_{4}}<p_{c}$, and the load of the other two switches in $red$, $green$, or $blue$ switch selection is less than $p_{c}$. Thus, a good solution is to upgrade three switches with the number of flows 5, 3, and 3 and deploy only two controllers.

II-B3 Maintaining the good propagation performance of flow requests by considering the locations of SDN switches and controllers

An SDN switch and a controller interact with each other in two ways: one SDN switch can send a flow request to the controller when it does not know how to process the flow, and a controller can dynamically change the paths of flows on its controlled SDN switches to improve the network performance (e.g., when identifying a congestion). Previous works [25][26] show that the propagation latency in WANs is the dominant factor among all latencies because the propagation latency bounds the control reactions of a controller that can be executed at a reasonable speed. A long propagation latency could limit availability (e.g., link failure recovery) and convergence time (e.g., network state pulling, routing convergence). Thus, for WANs, an important factor for controller placement is to minimize the total propagation delay among SDN switches and controllers. In WANs, the propagation delay of a request is proportional to the distance between a sender and a receiver. To maintain the good propagation performance of flow requests between the SDN’s control plane and data plane, we should minimize the propagation delay of flow requests between SDN switches and controllers, which motivates us to deploy controllers near the upgraded SDN switches.

In the example of $blue$ switch selection, the number of flows in switch $s_{4}$ is the largest one, and it is very close to the control capacity of a controller. Hence, we select switch $s_{4}$ to upgrade and deploy controller $c_{4}$ at location 4 for the switch. The rest two switches are switches $s_{5}$ and $s_{6}$, which can be controlled by a controller deployed at location 5 or 6. We use $M_{s_{i},c_{j}}$ to denote the mapping between switch $s_{i}$ and controller $c_{j}$. Since the delay between a switch and a controller is minimized when the controller is deployed at the same place of the switch, we have two candidate solutions: $blue_{1}=\{s_{4},s_{5},s_{6},c_{4},c_{5},M_{s_{4}c_{4}}\}$, $blue_{2}=\{s_{4},s_{5},s_{6},c_{4},c_{6},M_{s_{4}c_{4}}\}$.

II-B4 Impact of individual controller’s processing ability on controller-switch mappings

After selecting upgraded switches and deployed controllers, we should also map each upgraded switch to a controller for control. Each SDN switch can be managed by only one controller, and one controller could possibly manage multiple switches. Fig. 1(e) and 1(f) show two switch-controller mappings of the solution $blue_{2}$. In the two subfigures, switch $s_{4}$ is mapped to controller $c_{4}$, and switch $s_{6}$ is mapped to controller $c_{6}$. However, switch $s_{5}$ has different mappings. In Fig. 1(e), switch $s_{5}$ is mapped to controller $c_{4}$, and the controller’s load reaches $3+5=8$, which exceeds its maximum processing ability $6$ while the load of controller $c_{6}$ is only 3. Thus, the mapping between switch $s_{5}$ and controller $c_{4}$ is not allowed given that $s_{4}$ is already mapped to $c_{4}$. In Fig. 1(f), switch $s_{5}$’s mapping is feasible since its mapping to $c_{6}$ keeps $c_{6}$’s load at $3+3=6$, which does not exceed its maximum processing ability. Thus, switch-controller mappings without considering the controller processing ability constraint could also lead to an infeasible solution.

Fig. 1(g) shows a solution of $green$ switch selection. We use $D_{s_{i},s_{j}}$ to denote the distance (e.g., the length of the direct link or the shortest path) between switches $s_{i}$ and $s_{j}$. Because of $D_{s_{2},s_{5}}=2*D_{s_{6},s_{5}}$, we have $D_{s_{5},c_{2}}=2*D_{s_{6},s_{5}}$. One can check that optimal solutions of $blue_{1}$ and $blue_{2}$ switch selections outperform the optimal solution of $green$ switch selection in terms of the total propagation delay.

II-C Design criteria of the network upgrade

In the above network upgrade, we consider the following factors to upgrade a legacy network to the hybrid SDN:

maximizing the number of programmable flows from the upgraded SDN switches, 2. 2.

guaranteeing the processing performance of flow requests at controllers, and 3. 3.

minimizing the total propagation delay of flow requests between controllers and SDN switches.

The first factor depends on the upgraded switches. The second factor relates to the processing ability of individual controllers. The third factor must take the locations and mappings of controllers and SDN switches into consideration. By considering all these factors, an optimal result would come from a very complicated procedure since the factors couple with each other. For example, to get a better result, mapping selection in Section II-B4 could be determined before or simultaneously when selecting switches to upgrade and controllers to deploy. In the next section, we will formulate an optimization problem that takes into account all the above factors for an efficient network upgrade.

III Problem formulation

In this section, we first introduce constraints and objective functions and then formulate our optimization problem.

III-A System description

In a network upgrade from a legacy network to a hybrid SDN, we upgrade some of its switches to SDN switches and deploy some controllers to manage all SDN switches. The network consists of $N$ switches deployed at $N$ locations. The number of flows in switch $s_{i}$ is $R_{i}\geq 0\leavevmode\nobreak\ (1\leq i\leq N)$. We use homogeneous controllers, and the processing ability of controller $c_{j}$ is $A>0$ $(1\leq j\leq N)$.

We use $x_{i}=1$ to denote that switch $s_{i}$ is upgraded to the SDN switch; otherwise $x_{i}=0$. Similarly, we use $y_{j}=1$ to denote that controller $c_{j}$ is deployed at location $j$ and otherwise $y_{j}=0$; we use $z_{ij}=1$ to denote that an SDN switch $s_{i}$ is mapped to controller $c_{j}$ and otherwise $z_{ij}=0$. The default relationships between $x_{i}$, $y_{j}$, and $z_{ij}$ are shown below:

[TABLE]

[TABLE]

Equations (1) and (2) imply that a feasible switch-controller mapping must satisfy two conditions: a switch is upgraded to an SDN switch, and its mapping controller is deployed.

III-B Constraints

III-B1 Controller-switch mapping constraint

If switch $s_{i}$ is upgraded, it must be controlled by only one controller; if switch $s_{i}$ is not upgraded, it is not controlled by any controller. Thus, we have

[TABLE]

If controller $c_{j}$ is not deployed, it does not control any switches; if controller $c_{j}$ is deployed, it must control at least one SDN switch. That is:

[TABLE]

III-B2 Individual controller’s processing ability constraints

An SDN switch will send a flow request to a controller when it does not know how to process a new flow. The number of flow requests from an SDN switch equals the number of flows traversing the switch, and it should not exceed the controller’s processing ability. This can be mathematically written as

[TABLE]

Since both $x_{i}$ and $z_{ij}$ are binary variables, we substitute (1) into the above nonlinear constraints and reformulate them as the following linear constraints:

[TABLE]

III-B3 Upgrade budget constraint

The upgrade budget is that the total cost of upgraded switches and deployed controllers is at most $M>0$. The number of upgraded switches is $\sum_{i=1}^{N}x_{i}$, and the number of deployed controllers is $\sum_{j=1}^{N}y_{j}$. Suppose that the cost of an SDN switch is $\gamma\leavevmode\nobreak\ (\gamma\geq 1)$ times of the cost of a controller. Thus, we have

[TABLE]

III-C Objective functions

There are two objectives in our problem. The first one is to maximize the total number of flows by updating legacy switches to SDN switches:

[TABLE]

The second one is to minimize the total propagation delay of flow requests between SDN switches and controllers by deploying the controllers and mapping the SDN switches to the controllers. We use $D_{ij}\leavevmode\nobreak\ (D_{ij}\geq 0)$ to denote the propagation delay between SDN switch $s_{i}$ and controller $c_{j}$, which is proportional to their distance. Thus, we formulate the total propagation delay as follows:

[TABLE]

One main reason for upgrading traditional switches to SDN switches is to enjoy the benefit of programmability to flexibly select the route path. Many existing works adopt the first objective as their objectives [14][15]. The first objective decides the number and location of SDN switches in a network. The second objective is typically used to optimize the network performance for a network with given SDN switches [25][26]. In a hybrid SDN, the first objective is usually (much) more important than the second objective.

III-D Problem formulation

The goal of our problem is to maximize the number of flows from the SDN switches and minimize the total propagation delay of flow requests between the SDN switches and controllers by smartly upgrading legacy switches to SDN switches, deploying controllers, and mapping the SDN switches to the controllers. In practice, maximizing the number of programmable flows in our objectives has the first priority, and minimizing the total delay between the SDN switches and controllers has the second priority. Hence, we model the Joint Switch Upgrade and Controller Deployment (JSUCD) problem as a two-stage problem. In the first stage, we maximize the total number of programmable flows without considering the delay objective. This can be done by solving the following problem:

[TABLE]

With the maximum number of programmable flows obtained from problem (P1), we minimize the total delay by solving the following problem:

[TABLE]

The above two-stage problem formulation needs to solve two problems. An alternative formulation is to combine the two objectives into one objective as follows:

[TABLE]

where $\lambda\geq 0$ is a constant number that gives different weights of the two objective terms. In Section IV, we prove that by choosing the parameter $\lambda$ appropriately problem (P) is equivalent to the two-stage problem.

IV Problem analysis

In this section, we prove that under a certain condition, problem (P) is equivalent to the two-stage problem, and analyze the computational complexity of problems (P1), (P2), and (P).

IV-A Choice of the parameter $\lambda$ in problem (P)

Notice that if $D_{ij}=0$ for all $i$ and $j$, problem (P) is equivalent to problem (P1) for any $\lambda$. In this case, the objective function in problem (P2) is zero and hence problem (P) is equivalent to the two-stage problem. In the following, we show that even though there are $i_{0}$ and $j_{0}$ such that $D_{i_{0}j_{0}}\neq 0$, by appropriately choosing the parameter $\lambda$, this equivalence still holds.

Proposition 1**.**

Suppose all $R_{i}$ ($1\leq i\leq N$) are integers and there are $i_{0}$ and $j_{0}$ such that $D_{i_{0}j_{0}}\neq 0$. Let $d$ be the greatest common divisor of $R_{1},\ldots,R_{N}$, i.e., $d=\text{max}\{\bar{d}\ |\ \frac{R_{i}}{\bar{d}}\in\mathbb{Z},\ i=1,\ldots,N\}$. If

[TABLE]

then problem (P) is equivalent to the two-stage problem.

Proof: Notice that $\frac{d}{\sum_{i=1}^{N}\max_{1\leq j\leq N}\{D_{ij}\}}>0$ since $D_{ij}\geq 0$ for all $i$ and $j$ and there exist $i_{0}$ and $j_{0}$ such $D_{i_{0}j_{0}}>0$. In the following, we shall use the contradiction argument to show that the solution of problem (P) is also the solution of problems (P1) and (P2).

Let $(x^{*},y^{*},z^{*})$ be an optimal solution of problem (P). Assume that $(x^{*},y^{*},z^{*})$ is not an optimal solution of problem (P1). Then there exists an optimal solution $(\bar{x},\bar{y},\bar{z})$ of problem (P1) with $\sum_{i=1}^{N}R_{i}\bar{x}_{i}>\sum_{i=1}^{N}R_{i}x^{*}_{i}$. Because $R_{i}$, $\bar{x}_{i}$, and $x^{*}_{i}$ are all integers, by the choice of $d$, we have

[TABLE]

Since $\bar{x}_{i}=\sum_{j=1}^{N}\bar{z}_{ij}\leq 1$, it follows $\sum_{j=1}^{N}D_{ij}\bar{z}_{ij}\leq\text{max}_{1\leq j\leq N}\{D_{ij}\}\bar{z}_{ij}$, which, together with the choice of $\lambda$ in (9), further implies that

[TABLE]

Combining (10) with (11), we obtain

[TABLE]

where the last inequality follows from $D_{ij}\geq 0$ for all $i$ and $j$ and $\lambda>0$. However, this contradicts the fact that $(x^{*},y^{*},z^{*})$ is an optimal solution of problem (P). Hence $(x^{*},y^{*},z^{*})$ is also optimal for problem (P1). Let $F^{*}$ be the optimal value of problem (P1). Since adding the constraint $F^{*}=\sum_{i=1}^{m}R_{i}x_{i}$ to problem (P) does not change its optimal solution set, then it follows that the optimal solution of problem (P) is also optimal for problem (P2). Similarly, one can show that the optimal solution of problem (P2) is also optimal for problem (P). This completes our proof. $\square$

Proposition 1 shows that one-stage problem (P) with $\lambda$ satisfying the condition in (9) is equivalent to the two-stage problem, and hence we can solve problem (P) to obtain the desired result instead of solving two problems (P1) and (P2).

IV-B Complexity analysis

In this subsection, we analyze the computational complexity of problems (P1), (P2), and (P).

Proposition 2**.**

Problems (P1), (P2), and (P) are all strongly NP-hard.

**Proof: ** We only prove the strong NP-hardness of problem (P1) since the proof of the other two problems is similar. This can be done by establishing a polynomial-time reduction from the 3-partition problem, which is strongly NP-complete [28][29]. Next, we first introduce the 3-partition problem.

Given a finite set $\cal S$ of $3m$ elements, a bound $B\in\mathbb{Z}_{+}$, and a size $a_{i}\in\mathbb{Z}_{+}$ for the $i$-th element with $\frac{B}{4}<a_{i}<\frac{B}{2}$ and $\sum_{i=1}^{3m}a_{i}=mB$, can $\cal S$ be partitioned into $m$ disjoint sets ${\cal S}_{1},\ldots,{\cal S}_{m}$ such that $\sum_{i\in{\cal S}_{j}}a_{i}=B$, $1\leq j\leq m$?

Given any instance of the 3-partition problem, we construct an instance of problem (P1) as follows:

• set $M=4m$, $A=B$, $\gamma=1$, and $N$ to be any integer satisfying $N\geq 3m$;
• set $R_{i}=a_{i}$ for $i\in\{1,\ldots,3m\}$ and $R_{i}=0$ for $i\in\{3m+1,\ldots,N\}$.

By construction, the objective function in problem (P1) reduces to $\sum_{i=1}^{3m}a_{i}x_{i}$. It is easy to see that, for this constructed instance of problem (P1), there exists an optimal solution $(x,y,z)$ such that $x_{i}=0$ for $i\in\{3m+1,\ldots,N\}$ and $z_{ij}=0$ for $i\in\{3m+1,\ldots,N\}$, $j\in\{1,\ldots,N\}$.

Hence the constructed instance of problem (P1) can be written as

[TABLE]

In the following, we will show that the answer to the given instance of the 3-partition problem is true if and only if the optimal value of problem (P1’) is $mB$.

Suppose that $\cal S$ can be partitioned into $m$ disjoint sets ${\cal S}_{1},\ldots,{\cal S}_{m}$ such that $\sum_{i\in{\cal S}_{j}}a_{i}=B$ for all $j\in\{1,\ldots,m\}$. We construct a point $(\bar{x},\bar{y},\bar{z})$ by setting

1. $\bar{x}_{i}=1$ for $i\in\{1,\ldots,3m\}$;
2. $\bar{y}_{j}=1$ for $j\in\{1,\ldots,m\}$ and $\bar{y}_{j}=0$ for $j\in\{m+1,\ldots,N\}$;
3. $\bar{z}_{ij}=1$ for $i\in{\cal S}_{j}$, $j\in\{1,...,m\}$ and $\bar{z}_{ij}=0$ for the others.

Clearly, $(\bar{x},\bar{y},\bar{z})$ is a feasible solution of problem (P1’) with $\sum_{i=1}^{3m}a_{i}\bar{x}_{i}=mB$. As $\sum_{i=1}^{3m}a_{i}\bar{x}_{i}\leq\sum_{i=1}^{3m}a_{i}=mB$, we know the optimal value of problem (P1’) is $mB$.

Now suppose that the optimal value of problem (P1’) is $mB$ and the corresponding solution is $(\bar{x},\bar{y},\bar{z})$. Then $\sum_{i=1}^{3m}a_{i}\bar{x}_{i}=mB$. This, together with the fact that $\sum_{i=1}^{3m}a_{i}=mB$, implies $\sum_{i=1}^{3m}\bar{x}_{i}=3m$.

Then it must follow

[TABLE]

Otherwise, by $\sum_{i=1}^{3m}\bar{x}_{i}+\sum_{j=1}^{N}\bar{y}_{j}\leq 4m$, we know $\sum_{j=1}^{N}\bar{y}_{j}<m$. However, this is impossible since

[TABLE]

where the first equality follows from $\bar{x}_{i}=\sum_{j=1}^{N}\bar{z}_{ij}$ in problem (P1’) and the first inequality follows from $\bar{z}_{ij}\leq\bar{y}_{j}$ and $\sum_{i=1}^{3m}a_{i}\bar{z}_{ij}\leq B$ in problem (P1’). By (12), without loss of generality, we can assume that $\bar{y}_{j}=1$ for $j\in\{1,\ldots,m\}$ and $\bar{y}_{j}=0$ for $j\in\{m+1,\ldots,N\}$. We further show

[TABLE]

Otherwise, we have $\sum_{i=1}^{3m}a_{i}\bar{z}_{ij}<B$ for some $j$. From $\bar{y}_{j}=0$ for $j\in\{m+1,\ldots,N\}$ and $\bar{z}_{ij}\leq\bar{y}_{j}$, we know $\bar{z}_{ij}=0$ for $i\in\{1,\ldots,N\}$, $j\in\{m+1,\ldots,N\}$. Using this, we have $\sum_{i=1}^{3m}a_{i}\bar{x}_{i}=\sum_{j=1}^{N}\sum_{i=1}^{3m}a_{i}\bar{z}_{ij}=\sum_{j=1}^{m}\sum_{i=1}^{3m}a_{i}\bar{z}_{ij}<mB$, which contradicts the fact that the optimal value of problem (P1’) is $mB$. Now, let ${\cal S}_{j}=\{i\,|\,\bar{z}_{ij}=1,\,1\leq i\leq 3m\}$ for $j\in\{1,\ldots,m\}$. Then it follows from (13) that

[TABLE]

From $\bar{x}_{i}=\sum_{j=1}^{N}\bar{z}_{ij}$, we have ${\cal S}_{j_{1}}\cap{\cal S}_{j_{2}}=\emptyset$ for any $j_{1}$, $j_{2}\in\{1,\ldots,m\}$ with $j_{1}\neq j_{2}$. Furthermore, combining (13) with $\frac{B}{4}<a_{i}<\frac{B}{2}$, it follows $\sum_{i=1}^{3m}\bar{z}_{ij}=3$, or equivalently $|{\cal S}_{j}|=3$, $1\leq j\leq m$. This, together with the fact that ${\cal S}_{1},\ldots,{\cal S}_{m}$ are disjoint, indicates

[TABLE]

Hence the answer to the given instance of the 3-partition problem is true.

Finally, the above transformation can be done in polynomial time. Since the 3-partition problem is strongly NP-complete, we conclude that problem (P1) is strongly NP-hard. $\square$

Proposition 2 implies that, unless P=NP, there are no polynomial time algorithms, which can solve problem (P) to global optimality. Thus, we should develop efficient algorithms for approximately solving the problem especially when the dimension of the problem is large.

IV-C More insight into intrinsic difficulty of problem (P)

In the above subsection, we basically show that the problem of maximizing the total number of programmable flows is NP-hard. In this subsection, we study another two special cases of problem (P), i.e., the problem of minimizing the total propagation delay between controllers and SDN switches if all switches can be upgraded to SDN switches and all flows can be programmable, and show that they are still NP-hard. The analysis of the second case shows that there probably does not exist a constant-ratio approximation algorithm for problem (P). These analysis results provide more insight into the intrinsic difficulty of problem (P).

To simplify the following analysis, we replace constraint (5) in problem (P) with the following constraint

[TABLE]

Due to the binary nature of variables $y$ and $z$ and constraint (2), this replacement does not change the solution of the problem.

IV-C1 Case 1

In this case, we assume: (i) the processing capacity of the controller is large enough to control all switches’ requests, and (ii) the upgrade budget is large enough to upgrade all switches to SDN switches. Mathematically, the above two assumptions can be written as (i) $A>\sum_{i=1}^{N}R_{i}$ and (ii) $M-\gamma N\geq 1$. Under these two assumptions, we can reduce problem (P) via the following three steps. First, combining assumption (i) with constraint (2), we can see that constraint (14) becomes redundant for problem (P), and thus we can remove it. Second, the above assumptions (i) and (ii) can guarantee $x_{i}=1$ for all $i\in[1,N]$ in the optimal solution of problem (P). Hence, constraint (3) changes into

[TABLE]

and constraint (6) changes into

[TABLE]

Third, we can remove constraint (4) from problem (P). We argue this as follows: Let us suppose the optimal solution of problem (P) without constraint (4) is $(\bar{x},\bar{y},\bar{z})$ with $\bar{y}_{j}>\sum_{i=1}^{N}\bar{z}_{ij}$ for some $j\in\mathcal{J}\subseteq[1,N]$. By setting $\bar{y}_{j}=0$ for all $j\in\mathcal{J}$, we obtain a feasible solution for problem (P), which yields the same objective value as that at $(\bar{x},\bar{y},\bar{z})$. Combining the above three steps together, we can reduce problem (P) to the problem of selecting appropriate controllers to control all the SDN switches to minimize the total propagation delay as follows:

[TABLE]

The above problem is called p-Median Problem and is NP-hard [30]. Thus, problem (P) in this special case is also NP-hard.

IV-C2 Case 2

In the case, we assume: (i) all switches have the same number of flows and (ii) the upgrade budget is large enough to upgrade all switches to SDN switches and to deploy controllers to control all upgraded switches. These two assumptions can be written as (i) $R_{1}=\cdots=R_{N}\triangleq R$ and (ii) $(M-\gamma N)\lfloor\frac{A}{R}\rfloor\geq N,$ where $\lfloor\cdot\rfloor$ is the floor operator. Substituting assumption (i) into constraint (14), we obtain

[TABLE]

It is not difficult to argue that assumptions (i) and (ii) guarantee that $x_{i}=1$ for all $i\in[1,N]$ in the optimal solution of (P). Following steps 2 and 3 of case 1, we can reformulate problem (P) in this special case as follows:

[TABLE]

The above problem is called Uniform Capacitated $p$-Median Problem. It is a NP-hard problem, and existing studies do not find a constant-ratio approximation algorithm for it [31]. Our problem (P) is more general than the above problem. Based on the above analysis, we can conclude that there probably does not exist a good approximation algorithm for our problem (P).

V Problem solution

In this section, we propose an exact solution for solving the problem of small networks and an efficient heuristic algorithm for solving the problem of large networks.

V-A Exact solution

Typically, we can use existing integer program solvers to obtain problem (P)’s optimal solution. Here we use GUROBI solver [32] for solving our problem. GUROBI uses a branch-and-cut [33] framework and is recognized as one of the fastest integer program solvers [34]. The branch-and-cut framework usually uses Linear Programming (LP) relaxation to obtain an upper bound. However, the LP relaxation is usually very weak [35], and thus it is difficult for the solver to quickly solve the integer programming problem. In our experiments, we also observe the weakness of the LP relaxation of problem (P). To accelerate the solution process, we propose a better (re)formulation by strengthening some constraints and adding some valid inequalities by exploiting problem (P)’s structure.

V-A1 Strengthening constraints

First, we strengthen constraint (5) as (14). Compared to constraint (5), in (14) we use a tighter upper bound $A*y_{j}$, which improves the objective value of the LP relaxation of problem (P) and thus reduces the solution time of the branch-and-cut algorithm in GUROBI. The details can be found in [33].

V-A2 Adding valid inequalities

Generating efficient cutting planes is a key step in the branch-and-cut framework. In the mixed integer problems, one novel technique is to aggregate multiple constraints together to generate redundant but efficient constraints for the problem. This is because, in the mixed integer problems, some redundant constraints could be used as base constraints to generate cuts and may accelerate the solution process of the branch-and-cut framework [36]. Modern solvers can generate cuts automatically but usually do not consider the problem’s structure. By exploiting the structure of problem (P), below we add some aggregated constraints to problem (P) to help the solver efficiently generate cuts.

Adding all the constraints in (14) and using the constraints (3), we obtain

[TABLE]

Combining (18) with (6), we obtain the following inequality

[TABLE]

The inequalities (18) and (19) are redundant for the LP relaxation problem of (P), but they can be used as base constraints to help the solver to find some knapsack cuts [37] and further accelerate the solution process. The similar technique has been used for the problem of single-source capacitated facility location in [38].

Substituting (3) into the objective of problem (P), we have

[TABLE]

Based on the above analysis, we reformulate our problem as the final problem:

[TABLE]

where $x_{i}$, $y_{j}$, $z_{ij}$ are design variables and

[TABLE]

We will illustrate the effectiveness and efficiency of the new formulation with simulation results in Section VI-C.

V-B Heuristic algorithm

The new formulation helps the optimization solver to accelerate the solution process in small networks. However, it still requires a very long time or sometimes is impossible for the solver to find a feasible solution for the problem of large networks. In this section, we propose a heuristic algorithm for solving the problem to achieve the tradeoff between the performance and the time complexity. The heuristic algorithm is based on formulation (P’).

The intrinsic difficulty of our problem lies in the interrelationship of the selection of switches to upgrade, the selection of controllers to deploy, and the switch-controller mappings. Due to the interrelationship complexity of the three variables, we cannot change them at the same time. Based on our previous analysis, the mapping variables are more crucial (than switch update and controller deployment variables) since one mapping variable potentially can determine the other two variables. In the following part, we propose the MapFirst algorithm that determines the variables in the order of mappings, switches, and controllers.

The notations used in the algorithm are listed in Table I. The idea of our proposed algorithm, MapFirst, is to first select a switch-controller mapping in the descending order of their importance/weights and then tests whether building the mapping will satisfy the upgrade budget constraint: if yes, the switch and the controller in the mapping is selected; otherwise, a new mapping is tested. The procedure is terminated until there is no budget to build any mapping. Details of MapFirst are summarized in Algorithm 1. In line 1, at the beginning of the algorithm, the sets $\mathcal{X}$, $\mathcal{Y}$, and $\mathcal{Z}$ are set to be empty since no switches are upgraded, no controllers are deployed, and there are no mappings between switches and controllers. In line 2, we generate vector $\mathcal{Z}^{{vec}}=\{{z}^{{vec}}_{l},l\in[1,N*N]\}$. We first relax the binary variables in problem (P’) to continuous variables in [0,1], and get the LP relaxation solution $\mathcal{Z}^{*}$ of problem (P’). We then sort the solution $\mathcal{Z}^{*}$ in the descending order to get vector $\mathcal{Z}^{{vec}}$. The sorting operation enables us to test the mapping variables based on their probabilities. Next, we use our customized rounding technique to find the result by sequentially testing each ${z}^{{vec}}_{l}\in\mathcal{Z}^{{vec}}$. In line 4, we get ${z}^{{vec}}_{l}$’s corresponding switch index $i_{0}$ and controller index $j_{0}$. Lines 5-7 guarantee that we do not test a switch if it is already upgraded. In lines 8-18, we test the mapping between switch $s_{i_{0}}$ and controller $c_{j_{0}}$. If the mapping satisfies the constraints of problem (P’), we upgrade the switch and deploy the controller at two specific conditions: (1) in lines 9-12, controller $c_{j_{0}}$ is already deployed, and we only upgrade switch $s_{i_{0}}$ when the remaining upgrade budget is $\gamma$ or more; (2) in lines 13-16, controller $c_{j_{0}}$ is not deployed, and we upgrade switch $s_{i_{0}}$ and deploy controller $c_{j_{0}}$ when the remaining upgrade budget is $\gamma+1$ or more. If either of the two conditions is satisfied, we set the mapping between switch $s_{i_{0}}$ and controller $c_{j_{0}}$. In lines 19-21, if the remaining budget is less than $\gamma$, then we cannot upgrade any switch, and the algorithm returns the result and stops.

Fig. 2 shows an example of applying MapFirst to solve the problem. The mappings are tested in the decreasing order of the mappings’ weights. In the figure, the mapping $M_{s_{4},c_{4}}$ is first tested. Since the mapping satisfies the constraints in problem (P’), controller $c_{4}$, switch $s_{4}$ and the mapping $M_{s_{4},c_{4}}$ are selected. Then, the mapping $M_{s_{5},c_{4}}$ is tested but is not selected because the mapping does not satisfy the processing capacity constraint. Similarly, mappings $M_{s_{6},c_{6}}$ and $M_{s_{5},c_{6}}$ are tested one by one. If building one mapping does not violate the upgrade budget, the related switch, controller, and the mapping itself are selected.

V-C Worst-case complexity of MapFirst

As shown in Algorithm 1, MapFirst has two main steps: step 1 solves the LP relaxation and gets the weights by sorting the returned solution of the LP relaxation; step 2 generates a binary solution with a customized rounding technique. An LP can be solved in ${\cal O}(n^{3}*L)$ arithmetic operations by the interior-point methods, where $n$ is the number of variables and $L$ is the length of the input data of the problem [39]. Our problem has in total $N^{2}+2N$ variables, and the computational complexity of solving our LP relaxation is ${\cal O}(N^{6}*L)$. Sorting the returned solution of the LP relaxation takes ${\cal O}(N^{2}\log N^{2})$ operations, and the customized rounding procedure runs at most $N^{2}$ iterations. In summary, the dominant computational cost of MapFirst is to solve one LP relaxation, and its worst-case complexity is ${\cal O}(N^{6}*L)$. In sharp contrast, the branch-and-cut framework in the worst case needs to solve an exponential number of LP relaxations. Therefore, the worst-case complexity of MapFirst is significantly smaller than that of the branch-and-cut framework.

V-D A polynomial time solvable case

Our analysis in Sections IV-B and IV-C shows that problem (P) is NP-hard, and there probably does not exist a constant-ratio approximation algorithm for it. Therefore, our proposed MapFirst algorithm generally does not have a (constant-ratio approximation) performance guarantee. In this subsection, we consider a special case of problem (P), where each controller can control at most one SDN switch (i.e., $R_{i}+R_{j}>A$ for all $i\neq j$), and show that MapFirst is guaranteed to find the optimal solution of problem (P) in this special case.

Proposition 3**.**

If $R_{i}+R_{j}>A$ for all $i\neq j$, problem (P) can be solved (to globally optimality) in $\mathcal{O}(N^{3})$, and MapFirst is guaranteed to find the optimal solution of problem (P).

Proof.

Without loss of generality, we assume $0<R_{i}\leq A$ for all $i\in[1,N]$. Combining this assumption with the assumption $R_{i}+R_{j}>A$ for all $i\neq j$, constraint (14) reduces to $\sum_{i=1}^{N}z_{ij}\leq y_{j}$, which, together with (4), implies

[TABLE]

By substituting (5) and (21) into (6), we have

[TABLE]

From (21), we can simply remove constraint (2) from problem (P) and reformulate it as follows:

[TABLE]

Due to $R_{i}>0$ for all $i\in[1,N]$, the definition of $w_{ij}$ in (20), and the selection of $\lambda$ in (9), we know $\omega_{ij}>0$ for all $i,\leavevmode\nobreak\ j\in[1,N]$. Hence, inequality (22) can be rewritten as an equality, and problem (23) is a $k$-cardinality assignment problem. It has been shown in [40] that the LP relaxation of problem (23) is tight, i.e., solving the linear relaxation of problem (23) with an appropriate method (e.g., the simplex method) returns a binary solution. Furthermore, using the primal algorithm presented in [40], we can solve problem (23) with $\mathcal{O}(N^{3})$ complexity. The proof is completed. ∎

The above proposition shows that, if each controller can control at most one SDN switch, after some preprocessing steps, the LP relaxation in MapFirst is tight, and MapFirst can return an optimal solution of problem (P).

VI Simulation results

VI-A Simulation setup

In our simulation, we choose some backbone topologies from Topology Zoo [27] to evaluate the performance of our proposed solution. In the topologies, each node has a latitude and a longitude. Since the propagation delay of a flow request is usually proportional to the distance from a switch to a controller, we use the distance between two nodes to represent the propagation delay between an SDN switch and a controller. We use $M\_percent$ to denote the ratio of the given upgrade budget to the cost of upgrading all switches in the network. In our simulation, $M\_percent$ changes from 5% to 50%. We follow the assumption in [14][15] that the number of programmable flows in an SDN switch is proportional to the number of its links. In practice, we can analyze the traffic history at each switch to get the real traffic statistic. We have analyzed more than 50 topologies in Topology Zoo and find that most nodes have two or three links. We set the normalized processing ability of a controller $A=50$, and thus one controller is able to control at least ten SDN switches on average. Note that our problem can take into consideration of heterogeneous controllers by setting the processing abilities of different controllers with different values. The recommended system requirement of one OpenDayLight controller instance is 8 Cores, 8G RAM and 64GB storage [41], and the resilient three-controller deployment requires at least three physical servers and costs about $2000. One typical SDN switch is about$8000. Hence, we set the cost ratio between an SDN switch and one controller $\gamma=4$ .

VI-B Compared algorithms

Optimal: the optimal solution of problem (P’) that maximizes the number of programmable flows and minimizes the total propagation delay between upgraded SDN switches and controllers. We solve the problem by using GUROBI [32]. 2. 2.

FlowOnly: the optimal solution of problem (P1) that only maximizes the number of programmable flows. Problem (P1) is also solved by using GUROBI [32]. 3. 3.

MapFirst: we first use GUROBI [32] to solve the LP relaxation of problem (P’), and then use a customized rounding technique to sequentially determine the variables in the order of mappings, switches, and controllers. The details can be found in Section V-B. 4. 4.

WeightFirst: this algorithm is similar to MapFirst, but the key difference is that it greedily tests and picks the switch-controller mapping in the descending order of weights $\left\{w_{ij}\right\},i,j\in[1,N]$.

VI-C Effectiveness of formulation (P’)

We test the effectiveness of new formulation (P’) under different topologies from Topology Zoo [27]. We set a time limit of 3600 seconds for the branch-and-cut algorithm in GUROBI (i.e., we terminate the algorithm if it does not find the solution within 3600 seconds) and set $M\_percent=50\%$ for each topology. Table II summarizes the computational results. We can see from the table that: (1) for the problem instances Cogentco and Condensed_west_europe, GUROBI can successfully solve the new formulation (P’) within the given time limit but fail to solve the original formulation (P); (2) for the problem instances Colt, GtsCe, and Condensed, GUROBI can successfully solve both problem formulations within the given time limit but solving formulation (P’) takes significantly less time than solving formulation (P). These simulation results clearly show the effectiveness of formulation (P’), i.e., the newly added constraints (14), (18), and (19) indeed work and significantly accelerate the solution process.

VI-D *Performance of CPU time *

In the rest of this section, we focus on three topologies Att, Cernet, and Cogentco from Topology Zoo [27]. More specifically, Att is a small topology with 25 nodes and 57 links, Cernet is a medium-size topology with 41 nodes and 59 links, and Cogentco is a large topology with 197 nodes and 245 links. All of our simulations below are performed on these three topologies.

We use the ratio of the CPU time of an algorithm to that of MapFirst as the metric to measure the efficiency of the algorithm. Fig. 3 shows the results, where y-axis is in the $Log{10}$ scale. Recall that problem (P) is the original problem, and problem (P’) is problem (P) with strengthened constraints and valid inequalities. We can clearly observe from Fig. 3 that MapFirst is the fastest solution in all cases. More specifically, MapFirst is 499 and 5828 times faster than directly using GUROBI to solve problem (P) when M_percent = 45% for Att and M_percent = 25% for Cernet, respectively. In Fig. 3(c), we set a time limit of 3600 seconds for solving (P). We only get the results of M_percent = 10% and 20%, and we use the CPU time limit 3600 seconds as the CPU time of other cases of M_percent. In other words, GUROBI failed to solve problem (P) directly within 3600 seconds. However, for all cases of M_percent, GUROBI can successfully solve problem (P’) within the time limit. In fact, we can see from Fig. 3 that it is much more efficient to solve problem (P’) than problem (P) in most cases. These simulation results verify that problem (P’) is indeed a better formulation than problem (P) because added constraints and inequalities in (P’) are very effective to speed up the GUROBI solver, and our proposed MapFirst is effective.

VI-E Performance of programmable flows

Fig. 4 shows the performance of the programmable flows of different algorithms. In all the three topologies, the performance of the four algorithms increases as $M\_percent$ becomes larger. Optimal and FlowOnly are the optimal solutions to maximize the number of programmable flows. We can observe from Fig. 4 that WeighFirst’s performance is the worst and MapFirst’s performance is very close to that of Optimal and FlowOnly. Recall weight $\omega_{ij}$ is equal to $R_{i}-\lambda D_{ij}$ in WeightFirst. The maximum value of $\omega_{ij}$ is $R_{i}$ when deploying a controller at the location of a selected switch. Since $\lambda$ is usually a small value, $R_{i}$ plays the dominant role in $\omega_{ij}$ and thus WeightFirst first greedily tests the switch-controller pair based on the descending order of the number of flows in switches. Even though WeightFirst considers the delay in the later tests, it only focuses on a single switch-controller pair without the global view of the problem. In sharp contrast, MapFirst also tests the switch-controller pair but based on the result of the LP relaxation. The LP relaxation considers the entire problem to generate its result that reflects the probability of selecting switch-controller pairs. Therefore, the testing order of switch-controller pairs in MapFirst is more efficient than WeightFirst. This is the reason why MapFirst achieves much better performance than WeightFirst.

VI-F Performance of deployed controllers

Fig. 5 shows the number of controllers deployed by different algorithms under the three topologies. WeightFirst deploys more controllers than all the other algorithms since it always deploys a controller for each upgraded switch. Thus, under the same upgrade budget, WeightFirst upgrades fewer switches than all the other algorithms. FlowOnly performs the best since it does not consider the propagation delay in its objective function and deploys enough controllers for the upgraded SDN switches. Optimal deploys more switches than FlowOnly and MapFirst. Recall the cost ratio of an SDN switch and a controller is $\gamma$. If the upgrade budget is not enough to upgrade a switch, the rest budget can also be used to deploy 1 to $\gamma-1$ controllers. In this case, MapFirst and Optimal make different decisions: MapFirst does not deploy extra controllers and just stop the program (see lines 19-21 in Algorithm 1), while Optimal will deploy more controllers to minimize the propagation delay between SDN switches and controllers.

VI-G Performance of the propagation delay

Fig. 6 shows the propagation delay between SDN switches and controllers. In all topologies, WeightFirst performs the best as it deploys one controller at each SDN switch in most cases. Among all algorithms, FlowOnly performs the worst because problem formulation (P1) does not consider the propagation delay between SDN switches and controllers. In all the three topologies, Optimal and MapFirst’s propagation delays increase as $M\_percent$ increases, but their increasing rate is much lower than FlowOnly’s. Compared to MapFirst, Optimal achieves a better propagation delay performance since it deploys more controllers to minimize the propagation delay. From Fig. 5 and 6, we can see that in most cases, when MapFirst and Optimal deploy the same number of controllers, they have the same performance, except two cases $M\_percent=50\%$ in Fig. 5(a) and $M\_percent=15\%$ in Fig. 5(b). In these two cases, Optimal performs better than MapFirst even though they deploy the same number of controllers.

Fig. 7 shows the propagation delay between controllers. We do not show the results of WeightFirst because its performance is very bad. We can observe, from the figure, Optimal performs the worst since it does not consider this factor in the problem formulation (An interesting future is to consider the propagation delay in the problem formulation). FlowOnly performs better than Optimal since it deploys much fewer controllers than Optimal (see Fig. 5), and the deployed controllers are near to each other. In most cases, MapFirst has the best performance. This is because MapFirst always deploys the minimum number of controllers. In our problem formulation, we use the budget constraint to implicitly limit the number of controllers. In particular, our objective is to maximize the number of flows, which is equivalent to maximize the number of upgraded SDN switches. Given the upgrade budget, upgrading more switches will reduce the number of controllers to deploy.

VI-H Performance of controller control ability on switches

We use the ratio of the number of switches to the number of controllers to measure the controller control ability on switches. If a controller can control many switches, it will simplify the network control. Fig. 8 shows the controller control ability performance of all algorithms. In most cases, MapFirst performs the best since it upgrades the same number of switches as Optimal but deploys fewer controllers.

VI-I Summary of simulation findings

From our simulation results, we can conclude that the following two design principles of MapFirst are crucial: (1) among the three variables (i.e., the selection of upgraded switches, the selection of deployed controllers, and the mappings between SDN switches and controllers), the mapping variables are more important than the other two variables since they reflect the interrelationship between the other two variables, and (2) the solution of the LP relaxation can effectively reveal the importance of the mappings and thus the solution structure of the problem. WeightFirst only takes the first principle into consideration and performs the worst. Optimal performs the best in terms of the two objectives: maximizing the number of programmable flows and minimizing the propagation delay between SDN switches and controllers. However, it will deploy more controllers and has a higher propagation delay among controllers than MapFirst. More importantly, its worst-case complexity is significantly larger than MapFirst and WeightFirst. In summary, compared to Optimal, MapFirst not only achieves a comparable performance of the two objectives with significantly lower complexity but also deploys less number of controllers and thus has a shorter propagation delay among controllers. Considering all performance metrics, MapFirst achieves the best performance. Therefore, to efficiently handle a similar problem with interrelated variables, one can use our design principles.

VII Related works

The evolution from legacy networks to SDN is a long journey [42]. Considering SDN still being a fast developing technology, the full deployment of SDN not only requires a huge upgrade cost but also brings unexpected risks. The hybrid SDN is a promising alternative option and is receiving quickly increasing attention from industry and academia. Vissicchio et al. [43] first analyzed different models of hybrid SDNs. The research of the hybrid SDN can be categorized into two classes based on the application scenarios:

VII-A Layer 2 hybrid SDN

Panopticon [44] proposed an optimization framework to determine the partial SDN deployment and assumed that each flow in the network traverses at least one SDN switch. HybNET [45] designed a configuration mechanism to automatically translate network configurations between legacy networks and SDN networks. Telekinesis [46] manipulated forwarding entries in the legacy switches with a customized flow control primitive and enabled the forwarding flow on a user-defined path rather than the path in the spanning tree. Magneto [4] improved the work in [46] by providing more fine-grained flow controls and quick and stable user-defined path establishment.

VII-B Layer 3 hybrid SDN

VII-B1 Switch upgrade

Poularakis et al. [14] and Jia et al. [15] proposed to incrementally upgrade SDN to maximize the amount of programmable traffic under the given upgrade budget constraint. Xu et al. [47] compared the performance of hybrid SDNs by either replacing legacy devices with SDN devices or adding new SDN devices. Caria et al. [48] exploited the property of the network topologies and considered the centrality in the network to update switches in a hybrid SDN.

VII-B2 Traffic engineering

Agarwal et al. [7] first formulated an optimization problem for achieving traffic engineering in SDN with the partial deployment of SDN devices. Fibbing [9] introduced a centralized control over distributed IP routing by injecting crafted routing messages via OSPF and enhanced the flexibility, diversity, and reliability of L3 routing. Chu et al. [10] designed an approach to fast recover from single link failure while maintaining load-balancing performance for the post-recovery network. Wang et al. [11] and Jia et al. [12] explored power saving in Layer 3 hybrid SDN. Guo et al. [49] proposed to adjust the weights of links and flow split ratio at the SDN nodes to achieve load balancing in a given hybrid SDN. Hong et al. [8] proposed to satisfy a variety of traffic engineering goals in the hybrid SDN. However, all the above works did not introduce the real deployment of the SDN control plane and did not consider the impact of the control plane deployment on the hybrid SDN.

VII-C Multi-controller data plane

VII-C1 Controller deployment

Controller deployment is an important issue in multi-controller research. In WANs, the propagation latency is the critical part of the total latency [25][26], and some works aim to minimize the propagation latency among controllers and switches [50][51]. In data center networks, Wang et al. [52] proposed to dynamically map switches to controllers to mitigate the load imbalance among controllers and reduce the response time. Wang et al. [53] considered the maintenance cost of the controller cluster and assigned controllers to minimize the total cost of controller response time and maintenance on the cluster of controllers.

VII-C2 Resiliency

Resiliency is a critical concern for designing the multi-controller data plane. He et al. [54] presented to manage each SDN device with multiple controllers at the cloud to resist Byzantine attacks on controllers and the communication links between controllers and SDN switches. Hu et al. [55] [56] designed a fault-tolerant multi-controller control plane that mitigates the performance degradation of the controller chain failure caused by unreasonable slave controller assignment. MORPH [57] is a multi-controller framework, which is tolerant to unavailability failures of SDN controllers and Byzantine failures caused by malicious attacks by efficiently distinguishing and localizing faulty controller instances and appropriately reconfiguring the control plane. In the future, we will consider this factor to extend the work in this paper.

VIII Conclusion and future work

In this paper, we considered the impact of the control plane on the hybrid SDN and proposed to deploy the multi-controller control plane during upgrading a legacy network to a hybrid SDN. We formulated an optimization problem that jointly maximizes the number of flows from SDN switches and minimizes the propagation delay of flow requests between the SDN’s control plane and data plane under the given upgrade budget constraint. By carefully analyzing the problem’s structure, we proposed efficient solutions to solve the problem. The simulation results based on the real network topologies show the effectiveness and efficiency of our solutions. In the future, we will consider other practical factors in our problem formulation, such as the variation of the traffic pattern, the queuing delay in controllers, and multiple network upgrades.