Minimum weight controller tree design in SDN

Journal Pre-proof

Minimum Weight Controller Tree Design in SDN Ze Yang , Kwan L. Yeung PII: DOI: Reference:

S1389-1286(18)30282-2 https://doi.org/10.1016/j.comnet.2019.106949 COMPNW 106949

To appear in:

Computer Networks

Received date: Revised date: Accepted date:

25 May 2018 6 October 2019 10 October 2019

Please cite this article as: Ze Yang , Kwan L. Yeung , Minimum Weight Controller Tree Design in SDN, Computer Networks (2019), doi: https://doi.org/10.1016/j.comnet.2019.106949

This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2019 Published by Elsevier B.V.

Minimum Weight Controller Tree Design in SDN Ze Yang and Kwan L. Yeung Department of Electrical & Electronic Engineering The University of Hong Kong Pokfulam Road, Hong Kong Email: {yangze, kyeung}@eee.hku.hk Abstract—We consider an SDN based network with a single controller communicating with all the switches using a controller tree. When a switch is protected from the failure of its parent node using local fast reroute, its weight is 0; otherwise, its weight is the number of switches will be disconnected from the controller. In this paper, we study the problem of finding the minimum weight controller tree (mwCT), where the tree weight is the sum of all switch weights. Four original contributions are made. First, a new sibling protection mechanism is designed to maximize the number of protected switches. Second, we prove that the mwCT problem is NP-hard. Third, the first Integer Linear Programming (ILP) for solving the mwCT problem is formulated. Finally, an efficient heuristic algorithm for controller tree construction, called Distance-Degree Ordered Tree (DDOT), is proposed. Unlike ILP, DDOT minimizes not only the tree weight but also the average controller-switch distance. Index Terms—Minimum weight controller tree, local fast reroute, network survivability.

I. INTRODUCTION In a traditional IP network, a router functions at both control and forwarding planes. The notion of Software Defined Networking (SDN) [1-3] allows the decoupling of the control and forwarding planes, where switches (i.e., routers with major control plane functions removed) focus on packet forwarding, and a centralized controller is responsible for control plane functions. To properly conduct control plane functions such as keeping track network topology and traffic statistics, finding/installing paths for new flows, the controller-switch communications must be efficient and reliable. Since network component failure is inevitable, the controller-switch communications should be protected against any potential network faults [4-7]. Under the assumption of a single network component failure at a time, we follow the approach in [4-7] of connecting all switches to the controller using a spanning tree rooted at the controller. We call it a controller tree. Fig. 1 illustrates a controller tree rooted at node 1, where dashed lines are physical links and solid lines are the links used to form the controller tree. We call links on the controller tree on-tree links. All the controller-switch traffic is forwarded along the controller tree: packets from a switch are forwarded upstream toward the controller and packets from the controller are forwarded downstream toward a switch. When a switch/link fails, all switches at the downstream of the failed component will be disconnected from the controller. For the controller tree in Fig. 1, if switch 2 fails, all its downstream switches, i.e., 4 to 15, will

Controller 1 2

4 10

5

6

3

7

8

11

9 12

14

13 15

Fig. 1 A controller tree rooted at node 1. (Nodes in yellow are unprotected according to simple protection; among them, nodes with red-circle are protected by silbing protection.)

be disconnected from the controller. On the other hand, if link (9, 2) fails, only switches 9, 12, 14 and 15 will be disconnected. Without loss of generality, we assume every switch monitors its on-tree link to the parent switch, e.g., switch 9 monitors link (9, 2). If a loss of signal on link (9, 2) is detected, switch 9, called fault-detection switch, and its downstream switches, 12, 14 and 15, will be disconnected from the controller. A loss of signal can be caused by the failure of either link (9, 2) or switch 2. If the failure is at switch 2, switches 4 to 8 will also detect the loss of signal at about the same time. But it is impossible for an individual switch, e.g. switch 9 to tell the loss of signal is due to the failure of link (9, 2) or switch 2. But we know a switch failure always affects more switches than a corresponding link failure. As a result, whenever a failure is detected, we assume the worst case scenario that a switch failure occurs. If the fault-detection switch has a backup link, e.g., link (9, 3) of switch 9, local fast reroute can be immediately activated to bypass the failed component. In the example above, switch 9 will reroute its packets to the controller to link (9, 3). In doing so, all the downstream switches of 9, or switches 12, 14 and 15, will not be affected by the failure of switch 2. In fact, they do not even know switch 2 has failed because they are not the fault-detection switch. In this case, we say switch 9 is protected (and a formal definition of protection is given in Section II). Obviously, a backup link cannot be an on-tree link. In Fig. 1, if switch 9 (incorrectly) reroutes the packets onto on-tree link (9, 12), switch 12 will forward the packets back to switch 9 because switch 12 does not detect/know the failure. This creates a routing loop. On the other hand, not every non-tree link can function as a backup link. For example, non-tree link (9, 8) cannot be a backup link because if switch 9 reroutes its packets to (9, 8), switch 8 cannot forward the packets to the controller without going through switch 2.

A switch is unprotected if it does not have a backup link for protecting against the failure of its parent switch. When the parent switch fails, the unprotected switch, together with all its descendants in the tree, will be disconnected from the controller. Let the weight of a switch be the number of switches that will be disconnected when its parent node fails. Then the weight of a protected switch, e.g., switch 9, will be 0. Further let the weight of a controller tree be the sum of all switch weights. We can see that the weight of the controller tree in Fig. 1 is 29, due to the 10 unprotected/yellow switches. Intuitively a tree with a smaller weight is more robust to network component failures, and a tree with zero weight can survive from any single switch failures. In [4], an algorithm called Greedy Routing Tree (GRT) is proposed to construct minimum weight controller trees. GRT consists of two phases. In phase one, a shortest path spanning tree is constructed as the initial solution. In phase two, the initial tree is refined by finding a new parent for each switch if the weight of the new tree can be reduced. In [5], the weight definition is extended to differentiate between link failure and switch failure. But in practice, it is difficult to distinguish the two types of failures. In [6, 7], an extended signaling mechanism is proposed to protect a switch by tunneling the rerouted packets to a downstream switch that has a backup link to bypass the failed component, e.g., when switch 9 in Fig. 1 fails, switch 12 can tunnel the packets to switch 15 along path 12→14→15. Switch 15 can then forward the packets to 6 using backup link (15, 6). From switch 6 and onwards, packets can follow the on-tree path to reach the controller. But tunneling requires encapsulating each rerouted packet with a new header, and a new mechanism for informing the tunnel endpoint to activate its backup link. Last but not least, the path to reach the controller (after a failure) tends to be much longer. In this paper, the problem of finding minimum weight controller tree (mwCT) using local fast reroute is studied. Four major contributions are made in this paper. First, by making use of multiple backup links activated by the same switch failure, a new local protection mechanism called sibling protection is designed. Second, we prove that the mwCT problem is NP-hard. Third, we formulate the first Integer Linear Programming (ILP) to solve the mwCT problem. Finally, an efficient algorithm called Distance-Degree Ordered Tree (DDOT) is proposed to also minimize the average controller-switch distance. Note that if an SDN based network has multiple controllers, we can first partition/assign switches to be served by different controllers to minimize the average controller-switch distance. Then for each controller and its assigned switches, a controller tree can be constructed using either the ILP in Section III or the DDOT algorithm in Section IV. The rest of the paper is organized as follows. In Section II, sibling protection is introduced and the mwCT problem is formulated. In Section III, the ILP formulation for solving mwCT is presented. DDOT algorithm is detailed in Section IV and we evaluate its performance in Section V. In Section VI, some related work is discussed and we conclude the paper in Section VII.

II. MINIMUM WEIGHT CONTROLLER TREE PROBLEM A. Simple protection vs sibling protection In a tree topology, we define the root is at level 0 and nodes that are hops away (using on-tree paths) from the root are at level . Level 1 nodes are children of the root, and the root is the parent of all level 1 nodes. Nodes with the same parent are siblings. Node is a descendant of if is in the subtree rooted at node ; then node is an ancestor of . For the controller tree in Fig. 1, the set of unprotected/yellow switches are defined based on if simple protection is available [4]. Definition 1 (Simple Protection): If switch is at level ( ), it is protected by simple protection if and only if there exists a switch such that 

Switches



Switch

and

are connected by a non-tree link, and

is not a descendant of switch ’s parent.

If switch is at level 1, it is protected by simple protection if and only if there exists a switch such that 

Switches

and

are connected by a non-tree link, and



Switch is not a descendant of switch . According to the definition above, when switch 2 in Fig. 1 fails, among its six children only switch 9 can be protected. Note that when switch 2 fails, all six children will detect a failure happened instantaneously. Since switch 9 has an available backup link, i.e., link (9, 3), according to simple protection, the backup link will be activated. Note that, though link (8, 9) is not a qualified backup link for switch 8 according to simple protection definition, when it is configured as the backup link of switch 8, since it will also be activated when switch 2 fails, switch 8 can reroute the packets (destined to the controller) to 9, 9 will forward them to 3, and 3 will forward them to the controller without traversing the failed switch 2. In other words, switch 8 is protected using two backup links, (8, 9) and (9, 3), which are activated by the same failure and thus no coordination/signaling among switches is needed. We call the local fast reroute protection mechanism above sibling protection (because switches 8 and 9 are siblings). It is worth noting that a sibling protection always involves a simple protection. Sibling protection can have many manifestations and it is difficult to give a formal definition as Definition 1. But we can appreciate the effectiveness of sibling protection through some additional examples. In Fig. 1, switch 7 can be protected by sibling protection if link (7, 8) is configured as its backup link: When switch 2 fails, switch 7 activates backup link (7, 8) and reroutes the affected packets to 8. Since 8 is protected (by sibling protection), so is switch 7. Similarly, if switch 6 uses link (6, 15) as its backup link, it is also protected by rerouting the affected packets to switch 15; 15 then forwards them along path 15 14 12 9 to switch 9; since switch 9 is protected (by simple protection), so is switch 6. Following the same approach, we can see that switch 5 is protected using backup link (5, 6), and switch 4 is protected using backup link (4, 13). As a result, all six children of switch 2 are protected. With both simple and sibling protections, the weight of the controller tree is reduced from 29 to 21.

B. Problem formulation Let a -node SDN be modeled by an undirected graph G = , where is the set of nodes and is the set of bidirectional links with number | |. Throughout the paper, node and switch will be used interchangeably. Assume that the controller is placed at node , and denote the controller tree rooted at by and its weight by . Further denote a subtree rooted at switch by and its weight by . Note that and is also the weight of node . If a node is protected (by either simple or sibling protection), . The weight of the controller tree is the total weight of all (unprotected) nodes. To maximize the resiliency of the controller tree, should be minimized. Theorem 1: The minimum weight controller tree (mwCT) problem is NP-hard. The proof is based on a reduction from the SAT [18] problem and is detailed in Appendix-A. III. ILP FOR SOLVING THE MWCT PROBLEM In this section, we propose the first Integer Linear Programming (ILP) formulation to solve the minimum weight controller tree (mwCT) problem. For a given SDN network , we use (i, j) to denote the physical link between nodes and . Since only one direction of a physical link needs to be on-tree, we use 〈 〉 to denote a directed link from nodes to . A. Notations The complete list of notations needed for the ILP formulation are summarized below. [ ]. : Controller/root location, : Controller tree with controller at node . Binary variable. It equals to 1 if link 〈 and 0 otherwise. 〉:

〈

〉:

: A variable used to transform the non-linear objective into a linear expression. It has a minimum value of if node is unprotected, and 0 otherwise. B. ILP formulation From (1), the goal is to find the controller tree minimum weight . ∑

: A large constant serving as the normalization constant of the voltage difference between two nodes; . : The number of nodes in the subtree rooted at node , and including itself. .

: Binary variable. It equals to 1 if node is protected (by simple/sibling protection), and 0 otherwise. : Nodal degree of node . 〈 〉 : Binary variable. It equals to 1 if nodes and are siblings, and 0 otherwise.

(2)

.

Constraints (3)-(7) are used to guarantee found is a tree. Specifically, (3) makes sure only one direction of a link is used to form the tree ; (4) ensures that each node only has one parent; (5) specifies that the root/controller has no parent; (6) prevents routing loop by assigning each downstream node a higher “voltage” than its parent; and (7) bounds the total number of on-tree links to – 1. 〈

〉

〈 〈

〉

〉

〉

,

Binary variable. It equals to 1 if node is in the subtree rooted at node , and 0 otherwise.

(1)

,

〈

〉:

with the

Note that the weight of a controller tree is given by ∑ , which is non-linear. So we introduce another variable in (2) to transform the tree weight into a linear expression.

∑

: A small constant that serves as the minimum step of voltage increase along the tree (from root to leaf); .

: The weight of tree

Binary variable. It equals to 1 if node is protected via node and node is not a child of the root; it equals to 0 if node is unprotected or node is a child of the root. 〈

〉 is on-tree,

: An auxiliary voltage [21] value assigned to node on , .

〈

〈 〉 : Binary variable. It equals to 1 if node is protected via node and node is a child of the root; it equals to 0 if node is unprotected or node is not a child of the root.

〈

∑ 〈

〉

〈

〉

〉

(

〈

〉〈

〈

〉

〈

〉

〈

〉

(3)

. .

〉 .

(4) (5)

. 〈

〉)

〈

〉

.

(6) (7)

Constraints (8)-(18) define the descendant relationship among switches in . Among them, (8) makes sure node is on-tree. (9) says that if node is a descendant of node , node must not be a descendant of . (10) indicates that if node is a descendant of both nodes and , only one of the following two statements holds true: is a descendant of , or is a descendant of . (11) and (12) say that the root is not a descendant of any node, and any node must be a descendant of the root. (13) indicates that if (directed) link 〈 〉 is on-tree, node must be a child of . In (14), if node is a child of and link 〈 〉 is on-tree, node must be a descendant of . Similarly, (15) specifies that if is a child of , and is a child of , must be a descendant of . From (16), if and have the same parent, they are siblings and thus cannot be a descendant of each other. From (17), if has a lower auxiliary “voltage” than , must not be a descendant of . (18) further takes into account that if node is

a descendant of , node is a descendant of , and and are children of node , then and must not be a descendant of each other. (8)

.

〈 〉 〈

〉

〈

〈

〉

〈

(9)

.

〉 〉

〈

〉

〈

〉

. ,

〈

〉

〈

〉

〈

〉

〈

〉

〈

〉

〈

〉

〈

〉

〈

〈

〉

〈

〉

〈

〉

.

(11)

.

(12)

.

〉

. 〈

〉

〈

〉

〈

〈 〈

〉

(

〉

〉

〈

〈

〉

.

)

〉

〈

〉

(15)

(16) (17)

〉

〈

〈

〉

〈

〉

〉

.

(18)

With the descendant relationship defined by (8)-(18) above, the number of nodes in the subtree rooted at node can be found by (19). ∑

〈

〉

.

(19)

The sibling relationship of two nodes is defined by (20)-(26). With (20), the two nodes must be distinct. With (21), the root must have no sibling. (22) says that the sibling property is reciprocal between two nodes. And (23) defines that if and share the same parent, they are siblings. From (24), if and are siblings, they must not be a descendant of each other. Finally, (25) considers the situation that if link 〈 〉 is on-tree, and must not be siblings. Accordingly, (26) indicates that if two nodes do not share the same parent, they must not be siblings. 〈 〉

.

(20)

〈

〉

.

(21)

〈

〉

〈

〈

〉

〈

〉

〈

〉

〈 〈

(

〉

〈

〉

〈

〉

〈 〈

(

〈

〉

〈

〈

〈

〉

〉

.

〉)

. 〈

〉 〉

〉〈

〉

∑

〈

〉

∑

〈

〉

〈

〉

.

〈

〉

〈

〈

〉

(23)

.

〈

〈

〉

,

〈

〉

, 〈

〈

〉

(

〉

〈

〈 〈

〈 〈

〈

〉

(

〉

.

〉

(

〉

〉

(26)

(33)

〉 ))

〉

〈

〉

.

(34)

〈

〉

.

(35)

〉)

〈

〈

〉

If node is not a child of the root and yet is directly connected to the root, from (36) it is protected via the root. If node is not a child of the root and is not directly connected to the root, (37) checks if can be protected by simple protection via a node . Besides, (38) indicates that cannot be protected via its parent, node . Whether can be protected by sibling protection or not is determined using (39) and (40). 〈

〉

〈

〉

〈 〈

〈

(25)

.

(32)

.

〈

〈

〉

(

〉

〉 〉

〈

〉)

〈

〉

〈

〉

〈

〉

〉

.

(

〉)

〈

〈

〉

〈

〉

(

〈

〉)

∑

〈

〉

〈

(36) (

〈

〉)

.

〈 〉

(30)

.

Constraints (31)-(35) and (36)-(40) formulate the protection definitions for the nodes based on if they are children of the root (i.e., the calculation of 〈 〉 ) or not (i.e., the calculation of 〈 〉 ). If node is a child of the root (from (31)), it cannot be protected via the root (as stated in (32)). If is not a child of the root, 〈 〉 does not apply and we have 〈 〉 = 0 in (33). From (34), if is a descendant of , 〈 〉 = 0 because cannot be protected via a descendant. The only way to protect node is by simple protection, which is checked using (35). 〈 〉 〈 〉 . (31) 〈 〉 〈 〉

(24)

.

(29)

〉

〉

〉)

〈

(28)

〉)

〈

(22)

.

〉

〉

〈

. 〈

〈

(∑

(14)

〉

〈

∑

(13)

.

〉

〈

(10)

The protection definition of a node, i.e., the calculation of , is given by constraints (27)-(40). Here (27) says that the root/controller will never fail. For others, we use 〈 〉 and 〈 〉 to denote the protectability of node , depending on if it is a child of the root – as stipulated by (30). From (28) and (29), node is protected if there exists a node such that it can protect using simple/sibling protection. (27)

〉 〉

.

(37) (38)

〈 〈

〉

(

〈

〉)

〉

〈

(

〉)

〈

〈

〉

〉

. ∑

(39)

1

1 10

〈

〉

〈

9

8

7

4

5

6

10

9

8

7

3

4

5

6

〉

2

2

.

(40)

Recall that in Fig. 1, switch 7 is protected by sibling protection by rerouting its packets to the controller to sibling switch 8 via link (7, 8); as switch 8 is protected by sibling protection (via switch 9, which is protected by simple protection), switch 7 is protected. Focusing on this case, constraint (39) checks if node can be protected via its directly connected sibling , i.e., if is protected via a node . Note that switch 4 in Fig. 1 is also protected by sibling protection by rerouting its packets to the controller to a descendant (i.e., switch 13) of its sibling (i.e., switch 5), and this descendant is protected. Focusing on this case, constraint (40) checks if node is protected via a descendant (node m) of its sibling (node j), i.e., if node is protected via . IV. CONTROLLER TREE CONSTRUCTION ALGORITHM Solving the ILP formulated in the previous section is a formidable task especially if the network size is large. In this section, an efficient heuristic, called Distance-Degree Ordered Tree (DDOT), is designed. In addition to minimizing the tree weight, DDOT also aims at minimizing the average controller-switch distance (in hops), as well as bounding the worst case controller-switch distance. A. Issues with GRT Let us first take a closer look of GRT [4], the only existing algorithm for constructing minimum weight controller tree. GRT consists of two phases, initial controller tree construction and tree refinement process. The initial controller tree is constructed by randomly generating a shortest path tree (rooted at the controller). A shortest path tree minimizes the average controller-switch distance and is easy to construct (e.g. using Dijkstra’s algorithm), but finding a shortest path tree first can undermine the subsequent efforts of minimizing the tree weight. This is because shortest path tree tends to be “fat”. As a result, the close-to-root switches tend to be fully occupied by on-tree links. If a switch has no non-tree links, e.g., switch 2 in Fig. 1, it is impossible for it to be protected. Another example is shown in Fig. 2(a), a randomly generated shortest path tree for the Internet2 [19] topology (with controller placed at node 5). We can see that switches 3, 4 and 6 have no non-tree links. They are thus unprotected and the weight of the initial tree thus obtained is 2+6+2=10. (Note that the weight of the initial tree constructed by DDOT, as shown in Fig. 4(e), is 5.) In the second phase of GRT, the initial tree is refined. Starting from the switches at level 1 of the tree, each switch (say, ) is examined to see if a new parent (i.e., a neighbor connected by a non-tree link) can be found such that the weight of the tree can be reduced – in this examining process, the distance between the controller and switch is allowed to

3

(a)

(b)

Fig. 2 The initial (a) and final (b) controller trees found using GRT for the Internet2 topology, with controller at node 5.

increase by one hop, so as to enhance the chance of finding a new parent yet avoiding excessive distance increase. If a new parent is found, subtree is grafted to the new parent. This process continues until all switches are examined. Fig. 2(b) shows the final tree obtained by GRT, which has a weight of 7. Although a limit (of one hop) is set on the increase of distance while finding a new parent, it may not be effective in bounding the worst-case controller-switch distance because the path between the controller and a downstream switch, may be increased multiple times (whenever a parent change occurs) during the refinement process. Phase 1 of GRT has a time complexity of | | assuming Fibonacci Heap and adjacency list are adopted. In Phase 2, each switch is scanned for possible tree weight reduction. When a node is examined, all its neighbors will be checked for possible grafting, where is the nodal degree of node . Among them, the one reduced the weight most will be selected. The associated time complexity is ∑ . In the worst case, each node has neighbors, or . The associated time ∑ complexity of phase 2 becomes . Combining both phases, the total | | time complexity of GRT is | | . B. Distance-Degree Ordered Tree (DDOT) Our DDOT algorithm also consists of two phases, initial tree construction and tree refinement. Phase 1: Initial Controller Tree Construction In the initial tree construction phase, we start with the controller as the only node/root in the tree. Then a switch is selected for adding based on its distance to the root (along the shortest path) and its current number of non-tree links. Let be the longest shortest path from the root to the furthest away node in the network. We divide all the nodes into batches, and batch contains nodes that are -hop away from the root. All nodes in batch 1 are directly added to the tree, becoming the children of the root. Since the root is at level 0 of the tree, all nodes of batch 1 are at level 1. Keep in mind that only on-tree node has a level, and a level node can reach the root in hops (using on-tree path). Under the assumption that the controller never fails, this is the best strategy because it fully utilizes every link of the root to maximize the width of the tree (and thus potentially minimize its height).

Algorithm 1: Initial tree construction Input: 𝐺 𝑉 𝐸 ; controller location 𝑐; # of batches 𝐷 𝑃 1. Output: initial controller tree 𝑇𝑐 . 1: initialize 𝑇𝑐 with root at node 𝑐; 2: add all switch(es) in batch 1 to root 𝑐; 3: for 𝑘 2: 𝐷 𝑃, do /* batch-based adding process */ 4: rank nodes in batch k in descending order of their non-tree links; 5: for each node 𝑖 in batch k, do 6: for each node 𝑗 in batch k-1, do /* potential parent */ 7: if node 𝑗 has at least two non-tree links and 𝑖 and 𝑗 are neighbors /* parent found */ 8: add node 𝑖 to become a child of 𝑗; 9: break; 10: if no potential parent can be found 11: demote node 𝑖 from batch 𝑘 to 𝑘+1; 12: if batch 𝐷 𝑃 is not empty /* start forced-adding */ 13: for each node 𝑖 in batch 𝐷 𝑃 , do 14: find node 𝑗, a neighbor of node 𝑖, whose weight (after adding node 𝑖) is the smallest among all neighbors of node 𝑖; 15: add node 𝑖 to 𝑗; 16: return 𝑇𝑐 ; Fig. 3 Algorithm 1: Initial tree construction of DDOT.

For nodes in batch ( > 1), a batch-based adding process is conducted by first ranking all the nodes according to the descending order of their current number of non-tree links (and ties are broken randomly). Recall that a necessary condition1 for an on-tree node to be protected is that it must have at least one non-tree link. Besides, a node with more non-tree links will likely be protected with a higher chance, and when the tree is fully constructed, such a node tends to have more descendants. If a node with more descendants is protected, its weight is 0. As a result, the goal of our batch-based adding process is to leave a node on tree with at least one non-tree link whenever possible. To be more specific, starting from the first node in the ordered list, we try to add it to the tree by connecting it to a neighbor that is at level of the tree and has at least two non-tree links. If the neighbor only has one non-tree link, when the node is connected to it as a child, this neighbor will have no non-tree link left, becoming unprotected. If there are more than one neighbors at level meeting the adding requirements, the one with the largest number of non-tree links will be chosen. If there is no qualified neighbor at level , the node will be demoted to join batch . This demotion has two advantages. First, all level nodes remain having at least one non-tree link (meeting the necessary condition for protection). Second, the demoted node will be reconsidered in batch . When a node has been demoted multiple times, it will be pushed to the bottom of the tree, and will have a smaller weight if it cannot be protected. The batch-based adding process above will repeat until . If there are still non-tree nodes, all of them must have been demoted. The batch-based process can be repeated for another times, where can be set based on the maximum allowed controller-switch distance. If there are still non-tree nodes after batch ( ), they form the last batch, or batch . All nodes in the last batch will be added to the tree even if the adding would render a parent unprotected. We call it forced-adding. If there are multiple candidate parents, the one 1 At this stage, we do not know for sure if a node can be protected because the tree has not been fully constructed yet.

1 10

9

8

7

3

4

5

6

Demoted switch

1

2

10

9

8

7

3

4

5

6

2

(a) Batch 1

(b) Batch 2

1 10

9

8

7

3

4

5

6

1

2

10

9

8

7

3

4

5

6

2 (c) Batch 3

(d) Batch 4

1 10

9

8

7

3

4

5

6

2

(e) Batches 5 & 6 Fig. 4. An example showing the initial controller tree construction using DDOT. (Red-circled nodes are demoted.)

with the minimum weight (after adding) will be chosen. Note that the parent found using forced-adding can be located at any tree level. We summarize the initial controller tree construction above by Algorithm 1 in Fig. 3. It can be seen that the height of the initial controller tree obtained using Algorithm 1, i.e., the worst-case controller-switch distance, is always bounded by hops. An Example As an example, consider the topology in Fig. 4(a) with controller at node 5. Nodes 4, 6 and 8 are added to the tree in the first batch. In batch 2, there are three nodes, 3, 7 and 9. Ranking them in descending order of their number of non-tree links, we get an ordered list of {9, 3, 7}. We first consider node 9. It has two potential parents/neighbors, 4 and 8 (at level 1), each has two non-tree links. Assume node 8 is chosen. Node 9 is connected to 8 as a child, as shown in Fig. 4(b). Similarly, node 3 is connected to 4 as a child. For node 7, no potential parent can be found (because both nodes 8 and 6 only have one non-tree link). Node 7 is demoted to batch 3. In batch 3, there are three nodes, 2, 10 and (demoted) 7. Again, an ordered list is formed according to the number of non-tree links they have, or {2, 10, 7}. For node 2, since no potential parent can be found, it is demoted to batch 4. For node 10, it is added to the tree to become node 9’s child, as shown in Fig. 4(c). Node 7 cannot find a potential parent, and is thus demoted (again) to batch 4. In batch 4, the ordered node list is {1, 2, 7}. Node 2 is added to node 10 as a child, and nodes 1 and 7 are demoted to batch 5. Since the longest shortest path is =4 hops, all nodes in the network have been considered by now. But there are still two non-tree/demoted nodes, 1 and 7. Assume one extra batch-based adding processing is allowed, or . In batch 5, node 1 is added to 2 (at level 4), as shown in Fig. 4(e). The adding of node 7 fails again, so node 7 is demoted to the final batch, or batch

1

Algorithm 2: Tree refinement Input: 𝐺 𝑉 𝐸 , controller location 𝑐 initial tree 𝑇𝑐 , with height 𝐻 𝑇𝑐 and average controller-switch distance 𝐷 𝑇𝑐 Output: refined controller tree 𝑇𝑐 1: initialize level 𝑘 1, 𝐻 𝐻 𝑇𝑐 , 𝐷 𝐷 𝑇𝑐 ; initialize candidate tree set 𝐿 ∅; 2: 𝑇𝑐 _updated FALSE; /* to mark if the tree is updated */ 3: for level 𝑘 1 to 𝐻 do /* start a scanning cycle */ 4: if all switches are scanned 5: break; 6: for each node 𝑖 at level 𝑘, do 7: for each node 𝑗 which connects with 𝑖 via a non-tree link, do 8: if (𝛤( 𝑇𝑐 𝑖𝑗 ) 𝛤 𝑇𝑐 and 𝐻( 𝑇𝑐 𝑖𝑗 ) 𝐻 𝑇𝑐 ) or (𝛤( 𝑇𝑐 𝑖𝑗 )

𝛤 𝑇𝑐 and 𝐷( 𝑇𝑐 𝑖𝑗 )

𝐷 𝑇𝑐 )

The tree thus found has two unprotected nodes, 10 and 6, and the tree weight is . Note that although node 10 has one non-tree link, which meets the necessary condition of protection, but it is unprotected because when node 9 fails, rerouting to node 1 will form a loop. As compared to the initial controller tree in Fig. 2(a) using GRT, the weight of our initial controller tree is reduced from 10 to 5. Phase 2: Tree Refinement Let the average controller-switch distance (in hops) in be . In the second phase of our DDOT algorithm, the primary objective is to cut down tree weight ( ), and the secondary objective is to reduce average controller-switch distance . To be more specific, starting from the nodes at level 1 of , the following level-based scanning process is adopted. For each node i at level , let be the subtree rooted at node . Further let be the tree obtained by grafting to a new parent, say j (if available). becomes a candidate tree for refining if one of the following conditions is met: )

, or

.

(42)

(41) )

7

3

4

5

6

10

9

8

7

3

4

5

6

2

(b)

Fig. 6 Refining the initial tree in Fig. 4(e) using the second phase of DDOT.

6. In batch 6, forced-adding is used. From Fig. 4(d), we can force 7 to become a child of either 6 or 8. If node 8 is chosen, it will render node 8 unprotected with a weight of 6. If node 6 is chosen, node 6 will be unprotected with a weight of 2. Node 6 is chosen due to its smaller weight increase. As all nodes are now on-tree, the initial controller tree construction phase ends.

and (

8

(a)

9: 𝐿 𝐿 ∪ 𝑇𝑐 ; /* 𝑇𝑐 𝑖𝑗 is the tree built by grafting 𝑆𝑖 to 𝑗 ∗/ 10: if 𝐿 is not empty 11: find the tree with the biggest weight reduction; 12: if the biggest reduction is not zero 13: update 𝑇𝑐 with 𝑇𝑐 𝑖𝑗 ; 14: else if the biggest reduction is zero 15: update 𝑇𝑐 with the 𝑇𝑐 𝑖𝑗 that has the biggest 𝐷 𝑇𝑐 𝐷( 𝑇𝑐 𝑖𝑗 ) ; 16 goto step 6; 17: else /* 𝐿 is empty */ 18: 𝐻 𝐻 𝑇𝑐 ; /* update the height of the tree */ 19: if 𝑇𝑐 _updated TRUE 20: goto: step 1; /* start a new scanning cycle */ 21: else 22: return 𝑇𝑐 ; /* tree refinement ends */ Fig. 5 Algorithm 2: Tree refinement of DDOT.

(

9

2

𝑖𝑗

and

1 10

If the set of candidate trees is empty, proceed to scan nodes at level k = k+1. Otherwise, find the candidate tree that gives the biggest (nonzero) reduction in tree weight (say, ), and use it to update (i.e., ). If the biggest reduction in tree weight is 0, find the tree that has the biggest reduction in average controller-switch distance, and use it to update . Then for all other nodes at level k of (updated) , repeat the above process until the set of candidate trees is empty. When all levels of have been scanned, one scanning cycle is completed. A new scanning cycle will be initiated if has been updated in the current cycle. The tree refinement process above is summarized by Algorithm 2 in Fig. 5. Note that the tree height is (still) bounded by hops in the refinement process. An Example (continued) Let us refine the initial controller tree in Fig. 4(e) using Algorithm 2. The first scanning cycle starts from the nodes at level 1, or nodes 4, 6 and 8. None of them can find a new/better parent, meeting the condition in either (41) or (42). So the candidate tree set is empty and no update/refinement to the tree can be made. We proceed to scan the nodes at level 2 of , or 3, 7 and 9. Again, none of them can find a better parent. We proceed to level 3 and we only have node 10 at level 3. Obviously, if node 10 changes its parent from 9 to 1, the tree is no longer a tree; so again, no update to . (Note that no update to the tree is actually an indication that our initial tree construction algorithm is effective.) At level 4, we have node 2 only. If node 2 changes its parent from 10 to 3, although both new and old trees have the same weight of 5, the tree height can be reduced by 1, i.e., the average controller-distance will be reduced, or the condition in (42) will be met. So is updated by grafting to node 3 and the result is shown in Fig. 6(a). Since (updated) in Fig. 6(a) does not have level 5, the first scanning cycle ends. A new/second scanning cycle is needed because has been updated in the first cycle. In the second cycle, no update to the tree is possible in scanning the nodes from levels 1 to 3 of in Fig. 6(a). At level 4, we only have node 1. If the parent of node 1 is changed from 2 to 10, the tree weight can be reduced from 5 to 4, yet the tree height is not increased. This meets the condition in (41). So is grafted to node 10 and the result is shown in Fig. 6(b). Since all levels have been scanned, this completes our second scanning cycle. We then start the third scanning cycle based on in Fig. 6(b). This time no further update to is possible and the tree refinement process ends. As compared to the initial tree obtained by Algorithm 1 in Fig. 4(e), the weight of the refined

tree in Fig. 6(b) is reduced from 5 to 4, and the average controller-switch distance is reduced from 2.1 to 1.9 hops. C. Time complexity of DDOT The initial tree construction of DDOT is a batch-based adding process. The worst case is that each batch only contains one node. For each adding, the number of non-tree links will be checked and ranked, which has the time complexity. Since there are nodes to be added to the tree, the associated time complexity is . The tree refinement in phase 2 is a level-based scanning process. When a node is scanned, all its neighbors can be its possible parent, and the weight, average controller-switch distance and the height of the tree after graft will be calculated. Finally, the neighbor that reduces the weight or average controller-switch distance the most and with bounded tree height is selected for graft. The associated time complexity is ∑ . At the worst case, each node has neighbors, i.e., . The time complexity of ∑ phase 2 is then . Combining the time complexities of both phases, the total time complexity of algorithm DDOT is . V. PERFORMANCE E VALUATION

(a) Tree weight

(b) Average controller-switch distance Fig. 8 Performance comparison based on the US Network.

depends on the location of the controller.

In this section, we compare the performance of the following four controller tree construction algorithms:

 GRT: The original GRT algorithm [4] with simple protection only.

 DDOT: Our proposed algorithm with one extra batch-based adding processing allowed ( ). So the height of the tree is bounded by +2 hops. Note that the value of

 GRT-SS: GRT with both simple and sibling protections, a variant of GRT for studying the effectiveness of the sibling protection mechanism.  ILP: Our ILP defined in (1)-(40). Note that our ILP finds the

(a) Tree weight

(a) Tree weight

(b) Average controller-switch distance

(b) Average controller-switch distance

Fig. 7 Performance comparison based on the Internet2.

Fig. 9 Performance comparison based on the 20-node fat-tree in Fig. 12.

Protected by sibling protection 1 10

9

8

7

3

4

5

6

1

1 0

2

10

9

8

7

3

4

5

6

2

(a) GRT; 𝛤 𝑇3

(b) GRT-SS/DDOT/ILP; 𝛤 𝑇3 9, D

4, D

8

1 14

2

1 7

9

11 12

13

14

7

9

11

12

13

2

6

6

3

3

(a) GRT; 𝛤 𝑇

;D

(b) GRT-SP; 𝛤 𝑇 ,D 8

10 10

1 14

13

5

4

5

4

2

8

10

11

12

8

10 1 7

9

14

6

2

7

9

11 13

12

6

3

3 4

(c) DDOT; 𝛤 𝑇

,D

5

4

5

4

(d) ILP; 𝛤 𝑇

3

4

5

6

9

10

13

14

17

18

7

8

11

12

15

16

19

20

Fig. 12 A 3-level fat-tree with 20 nodes and 32 links.

Fig. 10 Controller trees found for the Internet2 with controller at node 3. 10 0

2

,D 6

Fig. 11 Controller trees found for the US network with controller at node 11.

minimum (optimal) tree weight, but does not consider the controller-switch distance. We focus on three representative topologies, the Internet2 in Fig. 2, the US network [20] in Fig. 11 and a 20-node fat-tree [21] in Fig. 12. In each topology, nodes are numbered and the location of the controller is changed from the first node to the last (i.e., x-axis in Figs. 7-9). At each controller location, a controller tree is found using each of the four algorithms above. The weight and the average controller-switch distance of the tree are calculated and plotted in Figs. 7-11. From Fig. 7(a), we can see that controller trees found by GRT based on the Internet2 topology always have the highest weight. With the additional sibling protection, GRT-SS cuts down the weight of GRT when the controller is placed at nodes 3 and 5. Notably, our DDOT provides the minimum tree weight at every controller location, identical to that obtained using ILP (optimal tree weight). From Fig. 7(b), we can see that trees obtained using ILP have the highest average controller-switch distance. This is because our ILP is not designed to minimize the controller-switch distance. On the other hand, controller trees found by algorithms DDOT, GRT and GRT-SS have comparable average controller-switch distance. In Fig. 10(a), the controller tree found by GRT with controller placed at node 3 is shown. There are 4 unprotected/yellow nodes and the total tree weight is 14. Under the same situation, the same controller tree is found by GRT-SS, DDOT and ILP and is shown in Fig. 10(b). It has a weight of 9. Specifically, nodes 1 and 5 are protected by sibling protection, via the recovery paths 1 10 9 4 3 and 5 8 9 10 2 3. Fig. 8 compares the four tree construction algorithms based on the US Network. From Fig. 8(a), we can see that GRT gives

the highest/worst tree weight; GRT-SS reduces the tree weight due to the additional sibling protection; DDOT provides close-to-minimum tree weight; and the minimum weight found by ILP is 0 at every controller location. From Fig. 8(b), GRT and GRT-SS provide the shortest controller-switch distance. This is because they both use a shortest path tree as the initial tree. But their tree refinement process is ineffective in reducing the tree weight. As a result, they tend to keep the original shortest path tree. Although the average controller-switch distance obtained by our DDOT is higher (yet bounded), DDOT provides much lower tree weight in Fig. 8(a), which is our primary objective. Besides, the value of in DDOT can be tuned to balance the tree weight and the average controller-switch distance. To gain more insights, Fig. 11 shows the four controller trees obtained by the four algorithms when the controller is placed at node 11. We can see that the tree in Fig. 11(a), obtained by GRT, has 4 unprotected nodes and with a weight of 15. Notably, when node 1 fails, node 2 cannot be protected by simple protection. But in Fig. 11(b), with GRT-SS, node 2 is protected by sibling protection (via the two-hop recovery path 234). Although the two trees in Figs. 11(a) & (b) are identical, their weights are different because node 2 is protected by sibling protection in Fig. 11(b). With DDOT, only node 12 in Fig. 11(c) is unprotected, and the corresponding tree weight is 2. The tree found using ILP is shown in Fig. 11(d) and its weight is 0 because all nodes are protected. But in this case, the average controller-switch distance is the highest. Fig. 9 compares the four tree construction algorithms based on the 20-node fat-tree in Fig. 12. From Fig. 9(a), the trees found by GRT have the highest weight, while GRT-SS reduces the tree weight by about 14.5% and the controller-switch distance by about 13.2% (see Fig. 9(b)). When DDOT is used, the tree weight is reduced by 71.8% and 67% with respect to GRT and GRT-SS, respectively. From Fig. 9(b), we can see that the average controller-switch distance using DDOT, though bounded, is about 1.8% and 16.7% higher than GRT and GRT-SS, respectively. As expected, ILP solutions have the smallest weight but highest controller-switch distance. VI. RELATED WORK In addition to the efforts of finding minimum weight controller tree [4-7], there are other approaches for protecting the controller-switch communications in SDN. For example, a pair of node disjoint paths can be established between each controller-switch pair [13, 14], thus any single link or node failure can be protected. To deal with multiple failures, the work in [15] aims at finding all possible disjoint paths between each

controller-switch pair. But protection based on disjoint paths requires additional signaling mechanism to inform the source node to activate the backup/disjoint path. Note that, when the failure is far from the source node, the signaling delay can be significant, causing severe traffic loss. There is another disadvantage of using disjoint path. As pointed out in [14], disjoint paths are stored as individual flow entries at all the switches along the paths. This greatly increases the flow table size. To reduce the flow entries needed, redundant trees such as blue/red trees [16] can be applied to SDN [17]. The idea is to construct two trees from the same root such that each switch has two disjoint on-tree paths to reach the root, one on each tree. Since on-tree paths are shared, the number of flow entries at switches can be reduced. But such a redundant tree solution requires an even more complicated signaling mechanism than that in [6, 7]. This is because when a node failure occurs, traffic from all of its descendants will be affected. To inform them to activate their backup/disjoint paths, individual and additional signaling to each source node is required. While in [6, 7], only the children of the failed node are involved. VII. CONCLUSION In this paper, we studied the problem of constructing minimum weight controller tree (mwCT). Four contributions were made. First, a new local switch protection mechanism called sibling protection was proposed. Then based on it, the mwCT problem was proved to be NP-hard. To solve it, we formulated the first Integer Linear Programming (ILP). As solving ILP is time-consuming and with no guarantee on the controller-switch distance, an efficient algorithm called distance-degree ordered tree (DDOT) was then proposed. Simulation results showed that the weight of the trees found using DDOT is much lower than an existing algorithm GRT, and is very close to the optimal solutions by ILP. Yet at the same time, the average controller-switch distance obtained using DDOT is bounded and is much shorter than that obtained using ILP. APPENDIX-A We prove that the minimum weight controller tree (mwCT) problem is NP-hard (Theorem 1) by showing that the decision version of the problem is NP-complete, using a reduction from the SAT problem [18]. We denote the decision version of the mwCT problem as problem : Given an undirected graph and a controller location , does there exist a controller tree such that its weight is at most ? We first consider the “yes” answer to problem , i.e., given a controller tree , its weight is equal to or smaller than a constant . In this case, a certifier can check the “yes” answer in polynomial time with the following steps. Step 1: for each switch , we can verify whether switch is protected by simple protection according to Definition 1 and a loosely defined sibling protection in Section II.B. Step 2: for each switch , the size of the subtree rooted at switch can be calculated. Step 3: for each switch , with whether it

is protected and its subtree size at hand, we can calculate its weight and the weight of the tree . As each step can be done in polynomial time, we can verify the “yes” answer to problem in polynomial time, so is in NP. To show that is NP-complete, we need to give a reduction from the SAT [18] problem, i.e., assume has a solution, we can express the solution in SAT Boolean equation. Assume the SAT problem consists of variables and their ̅ . The Boolean complements are denoted by ̅ ̅ equation of the SAT problem in Conjunctive Normal Form consists of m clauses, i.e., ＝ , and at least one variable or ̅ in each clause. We construct a controller tree to represent , and show that the weight of the tree is less or equal to if and only if is satisfiable. The construction of is completed by setting , i.e., a controller tree with all the switches are protected; and involves three blocks: root block, middle block and leaf block, as shown in Fig. 13(a). Here a square node is used to denote the controller, a circle node for a switch, bold lines for links on the tree, regular lines represent the same node, and dash lines for physical links in the network. Note that we decouple one single node into multiple connected same nodes to show how the different blocks are connected. The root block is built serving as constant true; i.e., all the switches in the root block are always protected. We use green circle and blue circle to distinguish the left child switch and right child switch of the root/controller, as shown in Fig. 13(b). In a middle block or a leaf block, as shown in Fig. 13(a), the non-tree link (shown in dashed line) connecting a switch in red circle, is associated with a variable from the clause. For notation convenience, we denote the link associated with a variable as a red non-tree link in Fig. 13. We then add middle blocks and leaf blocks to the tree such that all the switches can be protected by either simple protection or sibling protection with proper red non-tree link assignment, i.e., truth-setting of the variables in each clause. As shown in Fig. 13(b), a middle block including switches 3, 4, 5, 6, 11, 12 is added to be the subtree of switch 1, and the red non-tree link associated with variable is assigned to be connected with switch 2. As a result, all switches in the block are protected: switches 3, 4 and 5 are protected by sibling protection with recovery paths 3 4 12 5 6 2 c, 4 12 5 6 2 c and 5 6 2 c respectively; and switches 6, 11 and 12 are protected by simple protection with recovery paths 6 2 c, 11 5 1 c and 12 4 1 c respectively. Accordingly, we can assign true to variable , and conversely, we can constrain the variable associated with the red non-tree link to be false if such a red non-tree link does not exist. Note that if there are more than two variables ( ) in one clause, the associated block structure can be captured by merging blocks, as shown in Fig. 13(c). Accordingly, if there exists at least one red non-tree link that is connected to the green or blue switch properly (at least one variable in the clause is assigned true); all the switches in the block are protected by either simple protection or sibling protection.

c 1

Root Block

2

1

𝑥𝑢

𝑥𝑣

𝑥𝑢

Physical link On-tree link Same node

𝑥𝑢

4

3

𝑥

𝑥 5

2

6

7

8

9

10

13

14

5 𝑥̅ 𝑢

𝑥̅ 𝑢

Middle Block

12

11

Leaf Block

15

(a)

𝑥3

14

14

𝑥̅4 16

17

22

23

18

2

18

19

20

24

25

21

𝑥𝑣

𝑥𝑢

(b)

(c)

Fig. 13 (a) Three types of blocks and connections. (b) A sample controller tree with weight 0, representing 𝛷 representing a clause with 2 variables by concatenating 2 blocks.

Fig. 13(b) shows how to add/connect the blocks to produce a controller tree with all the switches protected, hence all the corresponding variables can be assigned true simultaneously, and is satisfiable. Suppose a Boolean equation of the SAT problem is satisfiable. Then each clause has at least one true assignment, and we can find a controller tree with all switches protected using the mapping method: For each clause in equation , we can transform it to a middle block or a leaf block. The block can be added to become the subtree of the green switch or blue switch in the root block randomly, and the true assignment variable or variables in the clause can be mapped to the assignment of the red non-tree link or links connecting to the green or blue switch in the root block accordingly, such that all switches are protected by either simple or sibling protection. After adding all the blocks to the tree sequentially, we complete the mapping. Such transformation only relates to the assignment of blocks and links, and can be done in polynomial time.

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

REFERENCES [1]

[2]

[3]

[4]

[5] [6] [7]

[8]

H. Kim and N. Feamster, “Improving network management with software defined networking,” IEEE Communications Magazine, vol. 51, no. 2, pp. 114-119, Feb. 2013. N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “Openflow: enabling innovation in campus networks,” SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69-74, Mar. 2008. S. Lin, P. Wang, I. F. Akyildiz and M. Luo, “Towards optimal network planning for Software-Defined Networks,” in Proc. IEEE Transactions on Mobile Computing, vol. 17, no. 12, pp. 2953-2967, 1 Dec. 2018. N. Beheshti and Y. Zhang, “Fast failover for control traffic in software-defined networks,” in Proc. IEEE GLOBECOM, Dec. 2012, pp. 2665-2670. N. Beheshti and Y. Zhang, “Controller placement for fast failover in the split architecture,” U.S. Patent 8804490 B2, August 12, 2014. N. Beheshti and Y. Zhang, “Controller placement for fast failover in the split architecture,” U.S. Patent 9225591 B2, December 29, 2015. Y. Hu, W. Wendong, G. Xiangyang, C. H. Liu, X. Que and S. Cheng, “Control traffic protection in software-defined networks,” in Proc. IEEE GLOBECOM, Dec. 2014, pp. 1878-1883. P. Fonseca, R. Bennesby, E. Mota and A. Passito, “Resilience of SDNs based on active and passive replication mechanisms,” in Proc. IEEE GLOBECOM, Dec. 2013, pp. 2188-2193.

[17]

[18] [19]

[20]

[21]

[22]

𝑥

𝑥

𝑥3⋁𝑥̅ . (c) Constructing a block

A. J. Gonzalez, G. Nencioni, B. E. Helvik and A. Kamisinski, “A fault-tolerant and consistent SDN controller,” in Proc. IEEE GLOBECOM, Dec. 2016, pp. 1-6. F. Botelho, A. Bessani, F. Ramos, and P. Ferreira, “On the design of practical fault-tolerant SDN controllers,” in Proc. IEEE 3rd European Workshop on Software Defined Networks (EWSDN), Sep. 2014, pp. 73– 78. V. Pashkov, A. Shalimov and R. Smeliansky, “Controller failover for SDN enterprise networks,” in Proc. IEEE International Science and Technology Conference (Modern Networking Technologies) (MoNeTeC), Sep. 2014, pp. 1-6. M. Tanha, D. Sajjadi and J. Pan, “Enduring node failures through resilient controller placement for software defined networks,” in Proc. IEEE GOBECOM, Dec. 2016, pp. 1-7. P. Vizarreta, C. M. Machuca and W. Kellerer, “Controller placement strategies for a resilient SDN control plane,” in Proc. 8th International Workshop on Resilient Networks Design and Modeling (RNDM), Jul. 2016, pp. 253-259. P. M. Mohan, T. Truong-Huu and M. Gurusamy, “TCAM-aware local rerouting for fast and efficient failure recovery in software defined networks,” in Proc. IEEE GLOBECOM, Dec. 2015, pp. 1-6. L. F. Müller, R. R. Oliveira, M. C. Luizelli, L. P. Gaspary and M. P. Barcellos, “Survivor: an enhanced controller placement strategy for improving SDN survivability,” in Proc. IEEE GLOBECOM, Dec. 2014, pp. 1909-1915. M. Medard, S. G. Finn, R. A. Barry and R. G. Gallager, “Redundant trees for preplanned recovery in arbitrary vertex-redundant or edge-redundant graphs,” in IEEE/ACM Transactions on Networking, vol. 7, no. 5, pp. 641-652, Oct 1999. M. Popovic, R. Khalili and J. Y. Le Boudec, “Performance comparison of node-redundant multicast distribution trees in SDN networks,” in Proc. International Conference on Networked Systems (NetSys), Mar. 2017, pp. 1-8. M.R. Gary and D.S. Johnson, Computers and Intractability: A Guide to the Theory of NP-completeness. W.H. Freeman and Co., 1979. S. Knight, H. X. Nguyen, N. Falkner, R. Bowden and M. Roughan, “The Internet Topology Zoo,” in Journal on Selected Areas in Communications, vol. 29, no. 9, pp. 1765-1775, Oct. 2011. R. Hulsermann, A. Betker, M. Jager, S. Bodamer, M.Barry, J. Spath, and M. Kohn, “A Set of Typical Transport Network Scenarios for Network Modelling,” ITG FACHBERICHT, vol. 182, pp. 65-72, 2004. M. Al-Fares, A. Loukissas, and A. Vahdat, “A scalable, commodity data center network architecture,” in Proc. ACM SIGCOMM, Aug. 2008, pp. 63-74. B. Wu, K. L. Yeung, and P.-H. Ho, “ILP formulations for non-simple p-cycle and p-trail design in wdm mesh networks,” Computer Networks, October 2009.

Ze Yang received his Ph.D. degree in Electrical and Electronic Engineering from the University of Hong Kong, Hong Kong

in 2018. His research interests include Software-Defined Networking (SDN) and hybrid SDN, with an emphasis on the network resilience and traffic monitoring.

Kwan L. Yeung received his B.Eng. and Ph.D. degrees in Information Engineering from The Chinese University of Hong Kong in 1992 and 1995, respectively. He joined the Department of Electrical and Electronic Engineering, The University of Hong Kong in July 2000, where he is currently a Professor, and the Information Engineering Program Co-Director. His research interests include next-generation Internet, packet switch/router design, all-optical networks and wireless data networks.