Primary-Backup Controller Mapping for Byzantine Fault Tolerance in Software Defined Networks

Mohan, Ponnusamy; Truong-Huu, Tram; Gurusamy, Mohan

doi:10.1109/glocom.2017.8254755

Cited by 22 publications

(21 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…BFT has recently been investigated in the context of distributed SDN control plane [5]- [7], [10]. In [5], [6], 3F M + 1 controller replicas are required to tolerate up to F M Byzantine failures. MORPH [7] requires 2F M + F A + 1 replicas in order to tolerate up to F M Byzantine and F A availability-induced failures.…”

Section: Background and Problem Statementmentioning

confidence: 99%

“…It furthermore ensures that a minimum number of required controllers, necessary to tolerate a number of availability failures F A and malicious failures F M , are loaded and associated with each switch. This task is also discussed in [6], [7].…”

Section: System Model and Design A P4bft System Modelmentioning

confidence: 99%

“…of matching messages required to deduce correct controller decisions, which we adopt in this work as well. [10] discusses the benefit of disaggregation of BFT consensus groups in the SDN control plane into multiple controller cluster partitions, thus enabling higher scalability than possible with [6] and [7]. While compatible with [10], our work focuses on scalability enhancements and footprint minimization by means of data-plane reconfiguration for realizing more efficient packet comparison.…”

Section: Processing and Reconfiguration Delaymentioning

confidence: 99%

See 2 more Smart Citations

P4BFT: Hardware-Accelerated Byzantine-Resilient Network Control Plane

Sakic

Ðerić²,

Goshi³

et al. 2019

2019 IEEE Global Communications Conference (GLOBECOM)

View full text Add to dashboard Cite

Byzantine Fault Tolerance (BFT) enables correct operation of distributed, i.e., replicated applications in the face of malicious take-over and faulty/buggy individual instances. Recently, BFT designs have gained traction in the context of Software Defined Networking (SDN). In SDN, controller replicas are distributed and their state replicated for high availability purposes. Malicious controller replicas, however, may destabilize the control plane and manipulate the data plane, thus motivating the BFT requirement. Nonetheless, deploying BFT in practice comes at a disadvantage of increased traffic load stemming from replicated controllers, as well as a requirement for proprietary switch functionalities, thus putting strain on switches' control plane where particular BFT actions must be executed in software.P4BFT leverages an optimal strategy to decrease the total amount of messages transmitted to switches that are the configuration targets of SDN controllers. It does so by means of message comparison and deduction of correct messages in the determined optimal locations in the data plane. In terms of the incurred control plane load, our P4-based data plane extensions outperform the existing solutions by ∼ 33.2% and ∼ 40.2% on average, in random 128-switch and Fat-Tree/Internet2 topologies, respectively. To validate the correctness and performance gains of P4BFT, we deploy bmv2 and Netronome Agilio SmartNICbased topologies. The advantages of P4BFT can thus be reproduced both with software switches and "commodity" P4-enabled hardware. A hardware-accelerated controller packet comparison procedure results in an average 96.4 % decrease in processing delay per request compared to existing software approaches.

show abstract

Section: Background and Problem Statementmentioning

confidence: 99%

Section: System Model and Design A P4bft System Modelmentioning

confidence: 99%

Section: Processing and Reconfiguration Delaymentioning

confidence: 99%

See 1 more Smart Citation

P4BFT: Hardware-Accelerated Byzantine-Resilient Network Control Plane

Sakic

Ðerić²,

Goshi³

et al. 2019

2019 IEEE Global Communications Conference (GLOBECOM)

View full text Add to dashboard Cite

show abstract

“…MORPH solves the controller-switch assignment problem during online operation using an Integer Linear Program (ILP) formulation. As a consequence, our switch agent applies the internal reconfigurations after receiving a maximum of F M +1 consistent/matching controller messages, thus minimizing the response time compared to [14] and [13] which require a minimum of 3F + 1 and F + 1 consistent messages to forward the switch state at any point in time, respectively. In MORPH, F M denotes the maximum number of tolerated Byzantine failures, whereas F A represents the number of maximum tolerated unavailabilityinduced failures.…”

Section: A Our Contributionmentioning

confidence: 99%

“…A good example is the addition of a new flow service in the network. Here, a PRIMARY controller may need to handle the request in the following manner: the art works [13], [14], however, do not distinguish Byzantine from availability-related failure sources, such as the failure of the underlying hardware, hypervisor or data plane links that interconnect the controllers. They consider the availabilityrelated failures a subset of Byzantine failures and thus tend to overprovision the required number of controller instances.…”

Section: Introductionmentioning

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

A comprehensive survey on software‐defined networking for smart communities

Chaudhary

Aujla

Kumar

et al. 2022

Int J Communication

View full text Add to dashboard Cite

The need to provide services closer to the end-user proximity leads to the exchange of a large volume of data generated from the smart devices deployed at different geo-distributed sites. The massive amount of data generated from the smart devices need to be transmitted, analyzed, and processed. This requires seamless data exchanges among geo-separated nodes, which results in a considerable burden on the underlying network infrastructure and can degrade the performance of any implemented solution. Therefore, a dynamic, agile, and programmable network management paradigm is required. To handle the challenges mentioned above, software-defined networking (SDN) gained much attention from academia, researchers, and industrial sectors.Shifting the computational load from forwarding devices to a logically centralized controller is a dream of every network operator who wants to have complete control and global visibility of the network. Also, the concept of network functions virtualization (NFV) in SDN controller is required to increase resource utilization efficiency. Thus, in this paper, a comprehensive survey on SDN for various smart applications is presented. This survey covers the infrastructural details of SDN hardware and OpenFlow switches, controllers, simulation tools, programming languages, open issues, and challenges in SDN implementation with advanced technologies such as 5G and microservices. In addition, the challenges on the control plane and data plane are highlighted in detail, such as fault tolerance, routing, scheduling of flows, and energy consumption on OpenFlow switches. Finally, various open issues and challenges future scope of SDN are discussed and analyzed in the proposal.

show abstract

Primary-Backup Controller Mapping for Byzantine Fault Tolerance in Software Defined Networks

Cited by 22 publications

References 9 publications

P4BFT: Hardware-Accelerated Byzantine-Resilient Network Control Plane

P4BFT: Hardware-Accelerated Byzantine-Resilient Network Control Plane

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

A comprehensive survey on software‐defined networking for smart communities

Contact Info

Product

Resources

About