Detour Planning for Fast and Reliable Failure Recovery in SDN with OpenState

Transcription

1 Detour Planning for Fast an Reliable Failure Recovery in SDN with OpenState Antonio Capone, Carmelo Cascone, Alessanro Q.T. Nguyen, Brunile Sansò Dipartimento i Elettronica, Informazione e Bioingegneria, Politecnico i Milano, Italy antonio.capone@polimi.it, alessanro.nguyen@mail.polimi.it Département e génie électrique, École Polytechnique e Montréal, Canaa carmelo.cascone@polymtl.ca, brunile.sanso@polymtl.ca arxiv: v2 [cs.ni] 1 Sep 215 Abstract A reliable an scalable mechanism to provie protection against a link or failure has aitional requirements in the context of SDN an OpenFlow. Not only it has to minimize the loa on the controller, but it must be able to react even when the controller is unreachable. In this paper we present a protection scheme base on precompute backup paths an inspire by MPLS crankback routing, that guarantees instantaneous recovery times an aims at zero packet-loss after failure etection, regarless of controller reachability, even when OpenFlow s fast-failover feature cannot be use. The propose mechanism is base on OpenState, an OpenFlow extension that allows a programmer to specify how forwaring rules shoul autonomously aapt in a stateful fashion, reucing the nee to rely on remote controllers. We present the scheme as well as two ifferent formulations for the computation of backup paths. I. INTRODUCTION Failure management is one of the funamental instruments that allows network operators to provie communication services that are much more reliable than the iniviual network components (s an links). It allows reacting to failures of network components by reconfiguring the resource allocation so as to make use of the surviving network infrastructure able to provie services. Traitionally, failure resilience has been incorporate in istribute protocols at the transport (like e.g. SDH) an/or network layer (like e.g. MPLS) with some optimization of resources pre-compute for a class of possible failures (like e.g. single link or failures) an implemente with signaling mechanisms use to notify failures an activate backup resources. With the introuction of the revolutionary an successful paraigm of Software-efine Networking (SDN), the traitional istribute networking approach is replace with a centralize network controller able to orchestrate traffic management through the programing of low-level forwaring policies into network s (switches) accoring to simple abstractions of the switching function like that efine in OpenFlow with the match/action flow table [1]. Even if SDN an OpenFlow provie huge flexibility an a powerful platform for programming any type of innovative network application without the strong constraints of istribute protocols, they can make the implementation of important traitional functions, like failure resilience, neither easy nor efficient, since reaction to events in the network must always involve the central controller (notification of an event an installation of new forwaring rules) with non-negligible elays an signaling overheas. New versions of OpenFlow [2] have recently introuce a mechanism, namely fast-failover, for allowing quick an local reaction to failures without the nee to resort on central controller. This is obtaine by instantiating multiple action buckets for the same flow entry, an applying them accoring to the status of links (active or faile). However, fast-failover can be use only to efine local etour mechanisms when alternative paths are available from the that etects the failure. Depening on network topology an the specific failure, local etour paths may not be available or they may be inefficient from the resource allocation point of view. A recent proposal (by some of the authors) [3], [4], name OpenState, has extene the ata plane abstraction of OpenFlow to inclue the possibility for switches to apply ifferent match-actions rules epening on states an to make states evolve accoring to state machines where transitions are triggere by packet-level events. In this paper, we propose a new approach to failure management in SDN which exploits OpenState ability to react to packet-level events in orer to efine a fast path restoration mechanism that allows to reallocate flows affecte by failure by enabling etours in any convenient s along the primary path. No specific signaling proceure is aopte for triggering etours, rather the same packets of the ata traffic flows are tagge an forware back to notify s of the failure an to inuce a state transition for the activation of pre-compute etours. We efine optimization moels for the computation of backup paths for all possible single an link failures that consier multiple objectives incluing link congestion level, istance of the reroute point from the failure etection point, an level of sharing of backup paths by ifferent flows. We show that the MILP (Mixe Integer Linear Programming) formulations propose are flexible enough to incorporate the optimization of the OpenFlow fast-failover reroutes as a special case an that path computation for all possible failure scenarios can be performe within reasonable time for realistic size networks with state-of-the-art solvers (cplex). The reminer of the paper is presente as follows. In Section II we first present an overview of OpenState an next we present the propose failure recovery scheme in Section III. Relate work is reviewe in Section IV an in Section V two moelling formulations are presente. Computational results

2 pkt heaers State table match key state DEFAULT heaers + state heaers + next-state Flow table match fiels heaers state actions SET_STATE next-state Fig. 1: Simplifie packet flow in OpenState. heaers + actions source 2 reroute PKT TAG PKT etect 1 merge primary path forwar back path etour estination are iscusse in Section VI. Conclusions are provie in Section VII. II. OPENSTATE The most prominent instance of SDN is OpenFlow, which, by esign, focuses on an extreme centralization of the network intelligence at the controller governing switches, which in turn are consiere umb. In OpenFlow, aaptation an reconfiguration of forwaring policies can only be performe by remote controllers, with a clear consequence in terms of overhea an control latency. OpenState is an OpenFlow extension that enables mechanisms for controllers to offloa some of their control logic to switches. In OpenState, the programmer is able to efine forwaring rules that can autonomously aapt in a stateful fashion on the basis of packet-level events. The motivation besie OpenState is that control tasks that require only switch-local knowlege are unnecessarily hanle at the controller, an thus can be offloae to switches, while maintaining centralize control for those tasks that require global knowlege of the network. OpenState has been esigne as an extension (superset) of OpenFlow. In OpenState the usual OpenFlow match/action flow table is precee by a state table that contains the so calle flow-states. First, packets are matche against the state table using only a portion of the packet heaer (a programmable lookup-key), a state lookup operation is performe an a state label (similar to OpenFlow s metaata) is appene to packet heaers. A DEFAULT state is returne if no row is matche in the state table. Packets are then sent to the flow-table where the usual OpenFlow processing is performe, while a new SET_STATE action is available to insert or rewrite rows of the state table with arbitrary values. Figure 1 illustrates the packet flow in the two tables. OpenState allows also to match packets using global-states, so calle because, in contrast to flowstates, these are globally vali for the whole switch (atapath) an not just for a given flow. By using flow-states an globalstates a programmer can efine flow entries that apply to ifferent scenarios, an by using state transition primitives she can control how those scenarios shoul evolve. OpenState has been showe to bring tangible benefits in the implementation of funamental network applications [4]. An open-source implementation of an OpenState controller an switch can be foun at [5], along with a moifie version of Mininet an few application examples. III. PROPOSED APPROACH The approach we take is similar to that use in crankback signaling [6]. In the context of en-to-en QoS in MPLS an GMPLS with RVSP-TE, when a connection or flow setup fails source PKT reroute TAG PKT 3 PKT etect 4 merge estination Fig. 2: Example of failure recovery with OpenState: in (1) the upstream etects the failure, tags the packet an forwars it back. In (2) the reroute receive the tagge packet, executes a state transition an forwar the packet on the etour. In (3) all the packets receive for the consiere eman after the state transition, will be tagge an forware on the etour. Finally in (4), at the en of the etour, the tag is poppe an the packet is forware on the primary path, towars its estination. because of a blocke link or, crankback is a signaling technique in which a notification of the failure is backtracke along the flow path, from the upstream that faces the blockage up to the first (calle repair point ) that can etermine an alternative path to the estination. Our solution is base on the same iea, but with the major ifference that, upon link or failure, the same ata packets, an not a notification, can be sent back on their original path. We istinguish two situations: (i) the which etects the failure is able to reroute the eman, an (ii) the packet must be forware back on it s primary path until a convenient reroute is encountere. In the first case, solutions like OpenFlow s fast-failover alreay guarantee almost instantaneous protection switching without controller intervention, while in the secon case it woul be impracticable to signal the failure to other s without the intervention of the controller. The novelty of our approach is given by the fact that, in the secon case, a crankback approach is performe using the same ata packets, which are first tagge (e.g. with a MPLS label containing information on the failure event) an then sent back trough the primary path. A reroute who receives the tagge packet will be able to respon to the failure by rerouting the tagge packets an by enabling a etour for all subsequent packets. That sai, only the first packets of the flow are sent back from the etect. As soon as the first tagge packet is processe by the reroute, a state transition is performe in the OpenState switch, an all subsequent packets coming from the source will be forware on the etour. An example of the mechanism escribe so far is summarize in Figure 2. With this approach, flow-states are use to istinguish the forwaring of each traffic eman at each switch. The DEFAULT state implies that the eman can be forware

3 towars the next on the primary path, other arbitrary states are use to escribe the specific failure that can affect the eman, so that the same reroute s can react ifferently accoring to the specific failure event. Global-states are instea use to escribe the operational status of switch ports (up or own). In this case global-states are completely equivalent to port liveness states use by OpenFlow fast-failover feature. Our proposal is currently inepenent of the way failures are etecte, because it oes not influence the moeling aspect of the solution. We assume it coul be implemente either via Loss Of Signal (LOS) or Biirectional Forwaring Detection (BFD) [7] mechanisms. In both cases, as soon as the state of the faile port is upate, our solution guarantees instantaneous reaction with ieally zero packet-loss. IV. RELATED WORK Failure management in SDN is a topic that has been alreay explore by the research community. In [8] the authors analyze the case of restoration for OpenFlow networks, showing how har it is to achieve fast (< 5ms) recovery times in large networks. Restoration is also taken into consieration in [9], where the controller is entitle to monitor link status on the network, an, in case of failure, it computes a new path for the affecte eman an replaces or eletes flow entries in switches, accoringly. In [1] an en-to-en path protection scheme is propose: OpenFlow 1.1 is extene by implementing in the switches a monitoring function that allows to reuce processing loa on the controller. Such a function is use in conjunction with OpenFlow fast-failover feature, thus allowing s to autonomously react to failures by switching to a precompute en-to-en backup path. In [11] a segment protection mechanisms is propose only for the case of link failure. Backup paths are pre-installe, an OpenFlow is extene to enable switches to locally react to connecte faile links. Another way to reuce the loa at the controller is presente in [12]. The authors propose a centralize monitoring scheme an a moel to reuce the number of monitoring iterations that the controller must perform in orer to check all links. A completely ifferent an creative approach is propose in [13], where classic graph search algorithms are presente to implement a solution base on the OpenFlow fast-failover scheme, where backup paths are not known in avance but s implement an algorithm to ranomly try new routes to reach the estination. V. PROBLEM FORMULATION Let G(N, A) be a symmetric irecte graph so that N represents the set of network switches, an A the set of links between switches. The emans are assume to be known in avance. Also assume is the fact that each eman will be route using a primary path optimize as a shortest-path with link capacity constraints. Our main problem then focuses on the evaluation of backup paths for each eman, for every possible single failure scenario in the primary path. The significance of a failure scenario will be clearly inicate in the next subsection. For comparison purposes we also present, at the en of the Section, a congestion avoiance version of the same backup path problem. A. Backup Path Problem Formulation In the forthcoming moel, we refer to failure etection event rather than simply failure state to inicate that a failure has been perceive. Moreover, instea of making an a priori istinction between the case of link an the case of failure, a fault etection event f = (n, m) may be either. The notation simply inicates that n etects a failure while transmitting to a ownstream m. Therefore two istinct situations are consiere: (i) a failure on link (n, m) (e.g. isconnecte or truncate cable, etc.) an (ii) a scenario where ownstream m fails implying the isconnection of all its ajacent links. When evaluating the backup path for a given eman, we always consier the worst-case scenario of a failure, thus completely avoiing to forwar packets to m, except for the case where m is also the estination of the consiere eman (m = t ). In such a case, we try to eliver packets to m avoiing the faile link (n, m). Let us now efine the following parameters: Parameters D set of emans to be route; s source of eman ; t estination of eman ; β ij is equal to if link (i, j) belongs to the primary path for eman, otherwise 1; b requeste banwith for eman ; c ij total capacity of link (i, j); w cap percentage of the link capacity available; F set incluing all the possible failure etection events (n, m) that can affect at least one primary path; D nm subset of D incluing all the emans affecte by the failure etection events (n, m); D1 nm subset of D nm incluing all the emans affecte by the failure etection event (n, m), when m is not the estination of the consiere eman an thus m t ; D2 nm subset of D nm incluing all the emans affecte by the failure etection event (n, m), where m is the estination of the consiere eman an thus m = t ; L m subset of A that will inclue all the links incient to m; u nm ij represents the use capacity of link (i, j) when link (n, m) fails. Note that in this parameter we consier only the link capacity allocate for those emans for which the primary path oes not inclue neither (m, n) or (n, m); vij m is the use capacity of link (i, j) in case of failure for m. In this case we consier only the link capacity allocate for those emans that are not affecte by a failure of m, in other wors those emans which primary path oes not inclue any of the links incient to m; p k represents the link (i, j) in the k-th position of the primary path for eman, where k = 1 is intene as the first link of the primary path starting from s ; λ nm is the number of s that a packet of eman traverses on the primary path, before reaching n of failure etection event (n, m). λ nm =

4 Decision variables y nm ij h nm z ij Objective Function means that the failure has been etecte by the first of the path. is equal to 1 if link (i, j) belongs to the backup path of eman in case of failure etection event (n, m), otherwise ; non-negative integer that represents the number of backwar hops that a tagge packet of eman must perform in case of failure etection event (n, m), before reaching the reroute that will enable the etour. When h nm = we mean that n that etecte the failure is also the reroute ; equal to if (i, j) is not use by any backup path (for every possible failure) for eman, otherwise 1. min (n,m) F + w h h nm D nm w y yij nm (n,m) F D nm (i,j) A + D (i,j) A w z β ij z ij (1) The objective function is compose of three weighte terms. The first minimizes the length of the reverse path that tagge ata packets must travel in case of failure. The secon minimizes the length of backup paths. The thir term minimizes the number of links allocate to the backup paths for a given eman, in other wors we want more backup paths of the same eman to share the same links. By using the three weights w h, w y, an w z we are able to characterize the behavior of the objective function in ifferent ways. Link availability constraints y nm ij (n, m) F, D1 nm (2) (i,j) L m y nm nm + y nm mn (n, m) F, D nm 2 (3) These constraints isable the use of certain links when evaluating the backup path for a given eman. Link capacity constraints u nm ij + b y nm ij + b e yeij mn w cap c ij D nm e D mn (n, m) F, (i, j) L (4) v m ij + n N: (n,m) F b y nm ij D nm w cap c ij m N, (i, j) L (5) The above constraints insure that for every possible failure, when allocating the backup paths, the link capacity must be respecte. The first set of constraints is specific for the case of link failure, while the secon set is specific for the case of failure. Because we o not know the exact nature of a failure etection event, we want our solution to be vali (in terms of resource allocation) in case of both link an failure. Flow conservation constraints j N: (i,j) A y nm ij j N: (j,i) A yji nm = 1, if i = s ; 1, if i = t ;, otherwise. i N, (n, m) F, D nm (6) These constraints assure that there is continuity in backup paths. Cycle avoiance constraints yij nm 1 i N, (n, m) F, D nm (7) j N: (i,j) L These constraints avoi the creation of cycles in the backup paths. Reverse path constraints λ nm k=1: (i,j)=p k (1 yij nm ) h nm (n, m) F, D nm : λ nm (8) These constraints are neee to evaluate the variable h nm. Capacity use constraints z ij y nm ij (i, j) A, (n, m) F, D nm (9) These constraints are neee to evaluate the variable z ij. Having reviewe the main backup path formulation, we now present, in the the next subsection a congestion avoiance formulation to be use for comparison purposes. B. Congestion Avoiance Formulation Let us first efine the following aitional variables: represents the maximum capacity use on link (i, j) w.r.t. all possible failure etection events; φ ij represents the cost of using link (i, j) when the capacity use is. The problem can then be formulate as follows Objective function min (i,j) A φ ij (1) This new objective function is a classical non-linear congestion relate optimization function that aims at minimizing the loa on each link. As we will later see, the function will be linearize in orer to treat the integer problem.

5 φij TABLE I: Topologies summary Topology N A N ege N core D Polska Norway Fat tree Link capacity constraints /(w cap c ij ) Fig. 3: Loa cost function φ ij Previous constraints (2), (3) an (6) are maintaine, while link capacity constrains (4) an (5) are substitute by the following: u nm ij + b y nm ij + b e yeij mn D nm e D mn (n, m) F, (i, j) L (11) v m ij + n N: (n,m) F b y nm ij D nm m N, (i, j) L (12) w cap c ij (i, j) L (13) (11) an (12) evaluate the maximum loa on link (i, j) for all consiere failure etection events (m, n), while (13) stipulates that even for the maximum value the capacity of the link must be respecte. Linearization constraints Given that φ ij in (1) is a non-linear performance function, it shoul be linearize by the following constraints: φ ij (i, j) A (14) w cap c ij φ ij 3 2 w cap c ij 3 φ ij 1 16 w cap c ij 3 φ ij w cap c ij 3 φ ij w cap c ij 3 (i, j) A (15) (i, j) A (16) (i, j) A (17) (i, j) A (18) This set of equations represent the linearize loa cost function shown in Fig. 3. VI. COMPUTATIONAL RESULTS The moel was teste on three ifferent network topologies portraye in Figure 4. Two real backbone topologies, namely Polska an Norway, taken from [14], an a fat tree, which is an example of a symmetric topology well known for its egree of fault-resiliency [15], an wiely use in ata centers. For each topology, s are ivie in two sets: ege s an core s. Ege s act as source an estination of traffic while core s are only in charge of routing. As mentione in Section V, one of the inputs of the moel is a set of primary paths evaluate as shortest paths for every traffic eman. Once such input was known, backup paths were foun by varying weights w h,w y, an w z of objective function (1). Three types of instances were evaluate for comparison purposes: those referring to the backup problem with a given set of weights, those referring to the congestion avoiance formulation an those referring to a classic en-to-en path protection formulation. A summary of such instances is given below: BP 111 BP 1 BP 1 BP 1 BP CA E2E all three terms of the objective function are taken into account; only the first term is consiere, thus the moel is force to fin a solution that minimizes the length of the reverse path, converging to a solution where failure etection an reroute are the same; only the secon term is consiere by minimizing the length of backup paths from s to t ; only the thir term is consiere, thus trying to minimize the number of links allocate for all backup paths of each eman; congestion avoiance formulation of the BP problem, minimizing the maximum loa for each link; classic en-to-en path protection problem formulation. The instances were execute assuming 2 ifferent link capacity sets c i,j : (i) capacity is set to the minimum value to obtain a feasible solution, an (ii) links are over-provisione with very high capacity. For each test the requeste banwith for each eman is always set to b = 1, an the available link capacity parameter is fixe to w cap = 8%. The moels were formalize an solve to optimality with AMPL-Cplex, using PCs with 8 CPU cores Intel Core i7 an 8GB of RAM. For all executions a solution was foun in less than 3 secons, except for the case of BP CA evaluate for the Norway topology, where the execution require about ten minutes. The solutions were compare evaluating the trae-off with respect to the following parameters: Backup path length: this measure was assesse with respect to the primary path length. A value of 1% means that the length of the backup path is twice the

6 (a) (b) (c) Fig. 4: Network topologies use in test instances: (a) Polska, (b) Norway, an (c) Fat tree primary path length, whereas % inicates that the two paths have the same length. Link capacity occupation: is the percentage of the total link capacity allocate for all primary an backup paths that use the consiere link. Reverse path length: is the portion of the primary path that a tagge packet has to traverse before being reroute. A value of 1% inicates that the packet has to go back to the source of the eman, while a % means that the packet is reroute from the same that etecte the failure. The complete set of results is shown in Table II an in chart form in Figure 5. In all instances BP 111 offers the best trae-off in terms of backup path length an reverse path length, with no major rawbacks. BP CA prouces better solutions in terms of link capacity occupation, especially when consiering instances with minimum capacity c ij (see Figures 5c, 5f an 5i for a clearer view). The rawback of using BP CA is represente by longer backup paths. In fact, for Norway an Polska topologies, BP CA prouces solutions with the longest backup paths, about the ouble in both cases (Figures 5a an 5). However, note that in the case of an on-line scenario BP CA woul guarantee more resiual capacity an thus a higher probability of accepting new traffic emans. Concerning the reverse path length, the best solution is obtaine with configuration BP 1 (Figures 5b, 5e, 5h). The rawback in this case is represente by longer backup paths, about the ouble when compare to primary paths. It is interesting to note that for the fat tree topology with c ij = 1 (Figure 5h) BP 1 returns a solution with reverse path length equal to %. This is worth mentioning because this solution woul be suitable to be implemente with OpenFlow fastfailover, where etect an reroute are always the same. Unfortunately such a solution is not always feasible, as it strongly epens on topology an capacity constraints. Inee, for all other cases, BP 1 is unable to provie a solution with % reverse path length. Thanks to this result we can show how our solution base on OpenState, which is able to hanle reverse paths, guarantees an higher egree of fault-resiliency when compare to a solution base on OpenFlow fast-failover. It is also interesting to note that for the Norway topology the given set of primary paths has no feasible solution for the E2E moel. This is ue to the fact that in the classic formulation of E2E path protection, primary paths an backup paths must be evaluate at the same time, thus avoiing the situation where for a given primary path is impossible to fin a completely isjoint backup path. We show in this case the flexibility of our approach by always proviing a feasible solution. Finally, it is interesting to note how for the case of the fat tree topology, the results obtaine from BP 111 are the same of the E2E moel, always having backup path length equal to primary paths, an reverse path length equal to 1%. This means that in case of failure, packets will be always reroute from the source of the eman. In this case a solution aopting OpenState woul guarantee less isruption thanks to the fact that s woul be able to automatically switch to the backup path, whereas OpenFlow woul require to forwar packet to the controller to enable the backup path at the source by installing the respective forwaring rules. VII. CONCLUSION In this paper we have presente a new failure management framework for SDN an a mathematical moeling approach specifically esigne to exploit the capabilities of OpenState. The framework consiers both single link an single failure. The protection scheme is base on the iea that, upon failure etection, packets can be tagge an backtracke along the primary path to signal the failure to the first convenient reroute, automatically establishing a etour path. Such scheme aims at having zero packet loss after failure etection, an oesn t require controller intervention. The moels were teste on three well-known topologies an comparative results were obtaine, showing the superiority of the scheme with respect to a classic en-to-en path protection scheme an with respect to an approach base on the OpenFlow fast-failover mechanism. We are currently working on the imensioning problem an eveloping the OpenState application to experimentally valiate the propose solution. ACKNOWLEDGMENT This work has been fune by NSERC Discovery Grant an by the European Community BEBA project. Luca Pollini an Davie Sanvito were part of the team that coe the algorithms in an OpenState emulator. We are grateful for their input that allowe us to assess upfront the feasibility of the propose moeling approaches.

7 Polska Backup path length BP 111 BP 1 BP 1 BP 1 BP CA E2E Reverse path length BP 111 BP 1 BP 1 BP 1 BP CA E2E Link capacity occupation BP 111 BP 1 BP 1 BP 1 BP CA E2E c ij = 14 c ij = 1 c ij = 14 c ij = 1 c ij = 14 c ij = 1 (a) (b) (c) Norway Backup path length BP 111 BP 1 BP 1 BP 1 BP CA Reverse path length BP 111 BP 1 BP 1 BP 1 BP CA Link capacity occupation BP 111 BP 1 BP 1 BP 1 BP CA c ij = 3 c ij = 3 c ij = 3 c ij = 3 c ij = 3 c ij = 3 () (e) (f) Fat tree Backup path length BP 111 BP 1 BP 1 BP 1 BP CA E2E Reverse path length BP 111 BP 1 BP 1 BP 1 BP CA E2E Link capacity occupation BP 111 BP 1 BP 1 BP 1 BP CA E2E c ij = 13 c ij = 1 c ij = 13 c ij = 1 c ij = 13 c ij = 1 (g) (h) (i) Fig. 5: Result charts for the three topology examinate

8 TABLE II: Computational results Instance Backup path length Link capacity occupation Reverse path length min max avg (var) min max avg (var) min max avg (var) BP 111 % 3% 48% (61%) 29% 79% 68% (1%) % 1% 36% (41%) BP 1 % 9% 8% (13%) 43% 79% 69% (9%) % 1% 6% (19%) Polska BP 1 % 3% 47% (61%) 43% 79% 68% (9%) % 1% 5% (45%) c ij = 14, (i, j) A BP 1 % 3% 52% (6%) 43% 79% 64% (12%) % 1% 92% (24%) BP CA % 7% 13% (123%) 7% 79% 54% (2%) % 1% 75% (43%) E2E % 3% 85% (75%) 29% 79% 64% (13%) 1% 1% 1% (%) BP 111 % 3% 48% (61%) 4% 12% 9% (2%) % 1% 43% (45%) BP 1 % 6% 15% (118%) 5% 16% 1% (2%) % 1% 4% (16%) Polska BP 1 % 3% 47% (61%) 6% 12% 9% (1%) % 1% 69% (43%) c ij = 1, (i, j) A BP 1 % 3% 5% (61%) 4% 11% 9% (2%) % 1% 97% (16%) BP CA % 7% 13% (136%) 2% 11% 7% (3%) % 1% 81% (39%) E2E % 3% 79% (77%) 3% 12% 9% (2%) 1% 1% 1% (%) BP 111 % 5% 32% (55%) 3% 8% 59% (2%) % 1% 42% (43%) BP 1 % 9% 79% (98%) 17% 8% 61% (18%) % 1% 15% (31%) Norway BP 1 % 5% 29% (53%) 7% 8% 58% (2%) % 1% 57% (42%) c ij = 3, (i, j) A BP 1 % 5% 4% (54%) 7% 8% 53% (2%) % 1% 91% (25%) BP CA % 16% 99% (137%) % 8% 45% (25%) % 1% 61% (49%) E2E BP 111 % 5% 29% (51%) % 12% 6% (3%) % 1% 31% (39%) BP 1 % 14% 94% (131%) 1% 14% 7% (3%) % 1% 4% (17%) Norway BP 1 % 5% 27% (52%) % 12% 6% (3%) % 1% 59% (42%) c ij = 3, (i, j) A BP 1 % 5% 36% (53%) % 12% 5% (3%) % 1% 93% (23%) BP CA % 14% 17% (138%) 1% 1% 4% (3%) % 1% 61% (49%) E2E BP 111 % % % (%) 15% 77% 59% (13%) 1% 1% 1% (%) BP 1 % 5% 67% (7%) 31% 77% 57% (13%) % 1% 4% (13%) Fat tree BP 1 % % % (%) 23% 77% 52% (13%) % 1% 97% (18%) c ij = 13, (i, j) A BP 1 % % % (%) 15% 77% 5% (14%) % 1% 1% (%) BP CA % 15% 13% (128%) % 77% 5% (15%) % 1% 85% (35%) E2E % % % (%) 15% 77% 5% (15%) 1% 1% 1% (%) BP 111 % % % (%) 1% 11% 6% (2%) 1% 1% 1% (%) BP 1 % 4% 75% (75%) 3% 12% 8% (2%) % % % (%) Fat tree BP 1 % % % (%) 2% 12% 7% (2%) % 1% 89% (31%) c ij = 1, (i, j) A BP 1 % % % (%) % 12% 6% (2%) 1% 1% 1% (%) BP CA % 2% 2% (35%) 1% 11% 6% (2%) % 1% 84% (36%) E2E % % % (%) % 12% 6% (3%) 1% 1% 1% (%) REFERENCES [1] N. McKeown, T. Anerson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexfor, S. Shenker, an J. Turner, OpenFlow: Enabling innovation in campus networks, SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, pp , Mar. 28. [2] Open Networking Founation, OpenFlow switch specification ver 1.4, Tech. Rep., Oct [3] G. Bianchi, M. Bonola, A. Capone, an C. Cascone, OpenState: programming platform-inepenent stateful OpenFlow applications insie the switch, SIGCOMM Comput. Commun. Rev., vol. 44, no. 2, pp , Apr [4] G. Bianchi, M. Bonola, A. Capone, C. Cascone, an S. Pontarelli, Towars wire-spee platform-agnostic control of OpenFlow switches, arxiv preprint arxiv: , 214. [5] OpenState SDN project home page, [6] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, an G. Ash, Crankback Signaling Extensions for MPLS an GMPLS RSVP-TE, RFC 492 (Propose Stanar), Internet Engineering Task Force, Jul. 27. [Online]. Available: [7] D. Katz an D. War, Biirectional Forwaring Detection (BFD), RFC 588 (Propose Stanar), Internet Engineering Task Force, Jun. 21. [Online]. Available: [8] D. Staessens, S. Sharma, D. Colle, M. Pickavet, an P. Demeester, Software efine networking: Meeting carrier grae requirements, in Local Metropolitan Area Networks (LANMAN), th IEEE Workshop on, Oct 211, pp [9] S. Sharma, D. Staessens, D. Colle, M. Pickavet, an P. Demeester, Enabling fast failure recovery in OpenFlow networks, in Design of Reliable Communication Networks (DRCN), 211 8th International Workshop on the, Oct 211, pp [1] J. Kempf, E. Bellagamba, A. Kern, D. Jocha, A. Takacs, an P. Skolstrom, Scalable fault management for OpenFlow, in Communications (ICC), 212 IEEE International Conference on, June 212, pp [11] A. Sgambelluri, A. Giorgetti, F. Cugini, F. Paolucci, an P. Castoli, OpenFlow-base segment protection in ethernet networks, Optical Communications an Networking, IEEE/OSA Journal of, vol. 5, no. 9, pp , Sept 213. [12] S. Lee, K.-Y. Li, K.-Y. Chan, G.-H. Lai, an Y.-C. Chung, Path layout planning an software base fast failure etection in survivable OpenFlow networks, in Design of Reliable Communication Networks (DRCN), 214 1th International Conference on the, April 214, pp [13] M. Borokhovich, L. Schiff, an S. Schmi, Provable ata plane connectivity with local fast failover: Introucing Openflow graph algorithms, in Proceeings of the Thir Workshop on Hot Topics in Software Define Networking, ser. HotSDN 14. ACM, 214, pp [14] S. Orlowski, R. Wessäly, M. Pióro, an A. Tomaszewski, SNDlib 1. survivable network esign library, Networks, vol. 55, no. 3, pp , 21. [15] R. Niranjan Mysore, A. Pamboris, N. Farrington, N. Huang, P. Miri, S. Rahakrishnan, V. Subramanya, an A. Vahat, PortLan: A scalable fault-tolerant layer 2 ata center network fabric, in Proceeings of the ACM SIGCOMM 29 Conference on Data Communication, ser. SIGCOMM 9. ACM, 29, pp