Availability Modelling of Software-Defined Backbone Networks

Nencioni, Gianfranco; Helvik, Bjarne E.; Gonzalez, Andrés J.; Heegaard, Poul E.; Kamisiński, Andrzej

doi:10.1109/dsn-w.2016.28

Cited by 25 publications

(17 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…SDN controller clusters that include five or a higher number of replicas per cluster have shown to posses negligible availability concerns. This confirms the claims made in [28], where authors discuss the minimal effect of long-term failure rates on the experienced downtime of an SDN control plane. short-term response time analysis we limit the complexity of the model by considering only the injected correlated failuresthis is realistic as only a very short time period (1s < x < 2s) is considered (see Figures 7 and 8).…”

Section: Model Complexity and Solve Timesupporting

confidence: 86%

“…We had experimentally injected bundle-and process-critical failures in sequence and then measured the subsequent recovery time required to re-stabilize the system. The distinguished mean bundle and software process repair times, measured during the controlled rejuvenation of the critical RAFT component sal-distributed-datastore and the ODL's controller process, ticked at 182.9ms and 26.9s respectively, far below the 3 minute recovery intervals previously proposed in literature [28], [30]. The measured recovery time purposely does not include the time needed to re-include the recovered node in the RAFT cluster, since this is modeled as a separate nondeterministic process in our SANs.…”

Section: B Fast Recovery Mechanism For Bundles and Processesmentioning

confidence: 68%

“…In state of the art literature, availability and overhead modeling of SDN has recently started to gain traction. In [28], the authors investigate the impact of operational and management failures on the availability in SDNs. They focus on the longterm availability impact of adding additional controllers, but do not include any response time analysis nor consider the impact of controller synchronization at micro-scale.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Response Time and Availability Study of RAFT Consensus in Distributed SDN Control Plane

Sakic

Kellerer

2018

IEEE Trans. Netw. Serv. Manage.

View full text Add to dashboard Cite

Software Defined Networking promises unprecedented flexibility and ease of network operations. While flexibility is an important factor when leveraging advantages of a new technology, critical infrastructure networks also have stringent requirements on network robustness and control plane delays. Robustness in the SDN control plane is realized by deploying multiple distributed controllers, formed into clusters for durability and fast-failover purposes. However, the effect of the controller clustering on the total system response time is not well investigated in current literature. Hence, in this work we provide a detailed analytical study of the distributed consensus algorithm RAFT, implemented in OpenDaylight and ONOS SDN controller platforms. In those controllers, RAFT implements the data-store replication, leader election after controller failures and controller state recovery on successful repairs. To evaluate its performance, we introduce a framework for numerical analysis of various SDN cluster organizations w.r.t. their response time and availability metrics. We use Stochastic Activity Networks for modeling the RAFT operations, failure injection and cluster recovery processes, and using real-world experiments, we collect the rate parameters to provide realistic inputs for a representative cluster recovery model. We also show how a fast rejuvenation mechanism for the treatment of failures induced by software errors can minimize the total response time experienced by the controller clients, while guaranteeing a higher system availability in the long-term.

show abstract

Section: Model Complexity and Solve Timesupporting

confidence: 86%

Section: B Fast Recovery Mechanism For Bundles and Processesmentioning

confidence: 68%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Response Time and Availability Study of RAFT Consensus in Distributed SDN Control Plane

Sakic

Kellerer

2018

IEEE Trans. Netw. Serv. Manage.

View full text Add to dashboard Cite

show abstract

“…The ordering of the different failure type injections is governed by the parametrization of mean arrival times as specified in Table III. The intensity of failures follows the negative exponential distribution (similar to [19], [40]).…”

Section: Internet2mentioning

confidence: 99%

MORPH: An Adaptive Framework for Efficient and Byzantine Fault-Tolerant SDN Control Plane

Sakic

Ðerić

Kellerer

2018

IEEE J. Select. Areas Commun.

View full text Add to dashboard Cite

Current approaches to tackling the single point of failure in SDN entail a distributed operation of SDN controller instances. Their state synchronization process is reliant on the assumption of a correct decision-making in the controllers. Successful introduction of SDN in the critical infrastructure networks also requires catering to the issue of unavailable, unreliable (e.g. buggy) and malicious controller failures. We propose MORPH, a framework tolerant to unavailability and Byzantine failures, that distinguishes and localizes faulty controller instances and appropriately reconfigures the control plane. Our controller-switch connection assignment leverages the awareness of the source of failure to optimize the number of active controllers and minimize the controller and switch reconfiguration delays. The proposed re-assignment executes dynamically after each successful failure identification. We require 2FM +FA+1 controllers to tolerate FM malicious and FA availability-induced failures. After a successful detection of FM malicious controllers, MORPH reconfigures the control plane to require a single controller message to forward the system state. Next, we outline and present a solution to the practical correctness issues related to the statefulness of the distributed SDN controller applications, previously ignored in the literature. We base our performance analysis on a resource-aware routing application, deployed in an emulated testbed comprising up to 16 controllers and up to 34 switches, so to tolerate up to 5 unique Byzantine and additional 5 availability-induced controller failures (a total of 10 unique controller failures). We quantify and highlight the dynamic decrease in the packet and CPU load and the response time after each successful failure detection.1) If the PRIMARY controller receives the client request, the task (e.g., path finding) is executed locally. 2) If a SECONDARY controller receives the client request, the request is proxied by the SECONDARY to the PRI-MARY controller, which then proceeds with request handling. If the PRIMARY controller fails, a new PRIMARY that handles the client request, is re-elected [9], [10].However, an occurrence of a Byzantine failure of the PRI-MARY controller (i.e. because of a corrupted [1], manipulated [11], or buggy [12] internal state), may lead to incorrect computation decisions in the controller logic. With Byzantine failures, there is incomplete information on whether the controller has truly failed. Thus, the controller may appear as both failed and correct to the failure-detection systems, presenting different symptoms to different observers (i.e. switches). Additionally, a malicious adversary may interfere with or modify the controller logic for the purpose of taking control of the network or re-routing the network traffic [11].On the other hand, availability-related controller failures lead to the controllers becoming inactive. In contrast to Byzantine failures, such controllers do not actively perform malicious actions nor do they try to hide their...

show abstract

“…In addition to the forwarding nodes, there are two dual-homed SDN controllers (SC 1 and SC 2 ), which are connected to TRD Fig. 2: Nation-wide backbone network Given this network, for computing and comparing the network availability of SDN with a traditional IP network we need to calculate the availability of the single network elements [12] or of the principal minimal-cut sets [5].…”

Section: Model Case Studymentioning

confidence: 99%

Including Failure Correlation in Availability Modeling of a Software-Defined Backbone Network

Nencioni

Helvik

Heegaard

2017

IEEE Trans. Netw. Serv. Manage.

Self Cite

View full text Add to dashboard Cite

Software-defined networking (SDN) promises to improve the programmability and flexibility of networks, but it may bring also new challenges that need to be explored. One open issue is the quantitative assessment of the properties of SDN backbone networks to determine whether they can provide similar availability to the traditional IP backbone networks. To achieve this goal, a two-level availability model that is able to capture the global network connectivity without neglecting the essential details and which includes a failure correlation assessment should be considered. The two-level availability model is composed by a structural model and the dynamic models of the principal minimal-cut sets of the network. The purpose of this technical report is to extensively present the implementation on Möbius of the Stochastic Activity Network (SAN) availability model of the network elements and the principal minimal-cut sets of a SDN backbone network and the corresponding traditional backbone network.• UHW R represent the recovery after an unsuccessful activation of the stand-by hardware with a rate of µ U H ;

show abstract

Availability Modelling of Software-Defined Backbone Networks

Cited by 25 publications

References 13 publications

Response Time and Availability Study of RAFT Consensus in Distributed SDN Control Plane

Response Time and Availability Study of RAFT Consensus in Distributed SDN Control Plane

MORPH: An Adaptive Framework for Efficient and Byzantine Fault-Tolerant SDN Control Plane

Including Failure Correlation in Availability Modeling of a Software-Defined Backbone Network

Contact Info

Product

Resources

About