,1,*, 牛晓彤,1, 高先明,2,*, 延志伟,3A Survey on Multi-controller Consensus Mechanisms
GUAN Jianfeng,1,*, NIU Xiaotong,1, GAO Xianming,2,*, YAN Zhiwei,3通讯作者: 关建峰（E-mail:jfguan@bupt.edu.cn）;高先明（E-mail:nudt_gxm@163.com）
收稿日期:2020-09-11网络出版日期:2021-02-20
| 基金资助: |
Received:2020-09-11Online:2021-02-20
作者简介 About authors
关建峰,北京邮电大学,副教授,IEEE会员,目前的研究方向包括网络架构、区块链与网络安全、移动互联网、大数据与人工智能等。在本文中承担论文整体架构设计指导与SDN可信基础设施。
GUAN Jianfeng is an associate professor at Beijing University of Posts and Telecommunications. His current research interests include network architecture, blockchain and network security, mobile Internet, big data and AI.In this paper, he is responsible for the overall framework design and guidance of credible SDN infrastructures.E-mail:
牛晓彤,北京邮电大学,硕士研究生,研究兴趣包括软件定义网络、共识机制与区块链。在本文中承担共识算法研究现状与SDN多控制器CFT类共识机制研究现状。
NIU Xiaotong is a graduate student at Beijing University of Posts and Telecommunications (BUPT), Beijing, China. Her research interests include software definition network, consensus mechanism and blockchain.In this paper, she is responsible for the research status of consensus algorithm and the research status of CFT consensus in the multi-controller layer of SDN.E-mail:
高先明,军事科学院系统工程研究院,工程师,研究兴趣包括智能网络、韧性网络。在本文中承担可信SDN安全服务及可信区块链基础设施部署方案。
GAO Xianming is an engineer at Institute of System Engineering, Academy of Military Science. His current research interests include intelligence network and resilience network.In this paper, he is responsible for the trusted SDN security services and blockchain deployment scheme.E-mail:
延志伟,中国互联网络信息中心,博士,研究员,主要研究方向为IPv6 移动性管理、BGP安全机制、信息中心网络架构。本文主要负责区块链共识算法。
YAN Zhiwei, Ph.D., is a researcher of China Internet Network Information Center. His main research directions are IPv6 mobility management, BGP security mechanism, and information center network architecture.In this paper, he is mainly responsible for the overall framework design and guidance.E-mail:
摘要
[背景]伴随着区块链逐渐应用于新一代互联网络的域名、路由、公钥等基础设施,其重要性日益彰显。作为区块链以及整个分布式系统领域的核心技术,共识机制直接影响着区块链的处理能力、可扩展性及安全性,也影响着其在互联网基础设施中的根基。[目的]对软件定义网络SDN (Software Defined Network) 中用于实现多控制器之间数据共享的共识机制设计进行综述,分析当前设计中存在的问题并提出解决方案,为相关研究工作提供参考。[方法]本文首先对共识机制的研究现状进行了概述,然后重点对SDN多控制器共识机制设计的研究现状进行了综述,对其中存在的问题进行了分析,并基于区块链技术提出了解决方案,介绍了当前将区块链技术应用于SDN网络的研究现状。[结果]当前SDN多控制器共识机制在实际部署中多采用以Raft为代表的宕机容错类共识机制,无法应对控制器或交换机等恶意行为,现有研究尝试引入拜占庭容错类共识解决该问题,并针对共识机制在SDN网络中的应用进行自适应设计以提高系统运行性能,但当前的SDN控制层中的用于实现控制器间数据共享的共识机制设计仍存在着共识网络部署不灵活、控制器运行共识机制带来巨大开销方面的问题。[结论]本文提出的基于区块链的控制器层数据共享第三方服务具有安全、可信、部署灵活等方面的优势,可为上述问题提供解决方案。本文提出的基于区块链的SDN网络可信基础设施作为数据共享服务的扩展架构,可为SDN提供多种安全可信服务。
关键词：
Abstract
[Background] With the increasing application of blockchain in infrastructures of the new generation of Internet in terms of the domain name, routing and public key system, the importance of blockchain is becoming increasingly prominent. As the core technology of blockchain or even the whole field of distributed system, consensus algorithms directly affect the transaction processing capacity, scalability and security of blockchain, as well as their role as a foundation in Internet infrastructure. [Objective] In this paper, we introduce the consensus mechanism for sharing data among multiple controllers in Software Defined Network (SDN), analyze the problems existing in the current design and propose solutions, and provide a reference for relevant research work. [Methods] Based on the classic distributed consensus algorithms, this paper summarizes the research status of consensus mechanism with a focus on the consensus in the multi-controller layer of SDN and the existing problems, proposes solutions based on the blockchain technology, and introduces the current research status of applying blockchain technology to SDN. [Results] The consensus mechanisms in the multi-controller cluster of SDN are mainly represented by Raft-like fault-tolerant consensus mechanisms in actual deployment, which cannot deal with the malicious behaviors to controllers or switches. Some existing researches have tried to introduce Byzantine fault-tolerant consensus mechanism, and improve the system performance adaptively. However, in the current SDN control layer, the consensus mechanism used to realize data sharing among controllers still has some problems, such as inflexible deployment of consensus network and huge cost caused by the controller consensus mechanism. [Conclusions] The third-party data-sharing service on controller layer based on blockchain proposed in this paper has advantages in security, credibility and flexible deployment, etc., which can provide solutions to solve the above mentioned problems. As an extended architecture of data sharing service, the credible blockchain-based SDN infrastructure proposed in this paper can provide a variety of secure and trusted services for SDN.
Keywords：
PDF (14389KB)元数据多维度评价相关文章导出EndNote|Ris|Bibtex收藏本文
本文引用格式
关建峰, 牛晓彤, 高先明, 延志伟. SDN多控制器共识机制研究综述. 数据与计算发展前沿[J], 2021, 3(1): 15-33 doi:10.11871/jfdc.issn.2096-742X.2021.01.002
GUAN Jianfeng, NIU Xiaotong, GAO Xianming, YAN Zhiwei.
引言
区块链技术作为“十三五”国家信息化规划中明确需要加强的前沿技术以及“新基建”信息基础设施的代表技术[1],对于我国抢占新一代信息技术的主导权具有重要的战略意义和广阔的应用前景。从本质上讲,区块链是一种分布式共享数据库,其使用散列以链式结构将区块组合起来,使得其数据存储具有去中心化、去信任化、不可篡改、可追溯、公开透明、集体维护等特征[2]。当前区块链作为一种应用层技术也在逐渐向网络基础设施方向发展[3],在域间路由、域名系统、公钥基础设施等领域崭露头角[4]。伴随着网络技术逐渐向软件化、虚拟化、可编程化等方向发展,网络安全也面临着新挑战,而区块链技术为解决这些安全问题提供了新方向。从技术层面而言,区块链是由多个参与方之间基于密码学、点对点通信、共识算法、智能合约、跨链通信等进行数据存储处理的技术组合。其中,共识算法是区块链乃至整个分布式系统领域的关键技术,决定了区块链系统（分布式系统）中各节点对需要进行处理的数据以何种机制达成一致,是近年来分布式系统领域研究的热点[5,6]。作为当前网络技术发展的一个重要方向,软件定义网络SDN (Software Defined Network)解耦了控制平面和数据平面,提出集中网络管控模式,将传统网络架构分拆为应用、控制、转发分离的架构,强调通过软件方式来定义网络行为,提升网络控制调度能力,其不但适用于专用网络提升网络部署维护的灵活性,还为广域网网络优化改进提供了新思路和新手段,其架构具有普适性。然而,当前SDN部署经验表明,将控制平面物理集中在可编程软件组件中,存在可扩展性、可用性、可靠性等限制[7],容易导致单点失效问题,给网络安全带来极大挑战[8],尤其是当控制器被劫持而恶意操纵网络或交换机被劫持而发送错误状态信息时,网络的安全运行将会受到严重威胁[9]。为此,出现一系列控制器集群方案通过状态或功能复制来解决这些问题[10]。这些方案往往利用共识算法,将相关数据复制给参与逻辑控制器集群的其它成员以达成一致。当某个控制器出现故障时,集群中另一个副本能够接管并继续为未来应用程序请求提供服务。然而,引入控制器集群实现逻辑集中的网络视图则面临着如何在多控制器间实现共识的问题。
1 共识算法研究现状
共识算法可分为经典分布式共识机制和区块链共识机制两大类：经典分布式共识机制面向整个分布式领域的共识问题,其在区块链应用场景中可适用于联盟链和私有链;而区块链共识机制主要为应用于公有链系统而设计。近年来,已有众多针对共识机制的综述类论文,文献[11]围绕拜占庭容错技术,对实用拜占庭容错（Practical Byzantine Fault Tolerance,PBFT）[12]以及其改进协议进行分类介绍。文献[13]侧重于研究经典分布式共识算法,并介绍了基于经典分布式共识算法实现的区块链应用。文献[14]针对区块链的可扩展性,分析了多种共识机制的交易处理能力以及可扩展性。文献[15]对Bitcoin、Ouroboros、ByzCoin和Omniledger等这四种典型区块链共识机制进行了分析。文献[5]给出了区块链共识机制的主流模型,并根据选主策略对共识机制进行分类,按时间顺序梳理和讨论了区块链共识机制的发展过程。文献[16]侧重于研究区块链共识机制,对共识机制进行了分类并介绍了各类经典共识机制的流程。文献[17]研究了区块链共识机制的分类问题,对网络模型、敌手模型等协议假设进行了介绍。本文则主要针对SDN网络的分布式控制器集群中的共识机制进行研究,本节对共识算法研究现状进行介绍,为后续多控制器共识机制研究进展奠定基础。
1.1 经典分布式共识算法
经典分布式共识算法可以根据故障模型、网络模型、部署方式等进行分类。根据假设条件中的故障模型的不同,可以分为崩溃容错（Crush Fault Tolerance, CFT）类共识算法和拜占庭容错类（Byzantine Fault Tolerance, BFT）共识算法;根据网络模型的不同,可以分为同步网络共识算法、异步网络共识算法、部分同步网络共识算法;根据敌手模型的不同,可以分为敌手模型为n=2f+1、n=3f+1、n=5f+1等的共识算法;根据算法一致性的强弱,可以分为强一致性共识、弱（最终）一致性共识。对经典分布式共识算法的研究可追溯到1975年Akkoyunlu等提出了计算机领域的两军问题[18]。1982年,Lamport等提出了拜占庭将军问题[19],开启了对拜占庭容错技术的研究。1998年,Lamport提出了Paxos算法[20],该算法作为CFT类共识算法,对宕机节点具有容错能力,在不超过1/2的节点发生崩溃的情况下,保证诚实节点能够对数据达成共识。Raft算法[21]基于Paxos算法进行了改进,通过将共识问题分解为领导者选举、日志复制和安全三个子问题,提供了与Paxos算法相同的功能和性能,但更容易理解和应用。1999年,Castro和Liskov提出了PBFT协议,首次将拜占庭协议的复杂度从指数级降低到多项式级别,使拜占庭协议在分布式系统中被应用成为可能。同时,针对PBFT算法的主节点正常共识流程的通信复杂度高、计算开销大等问题,涌现了一系列PBFT改进优化算法,主要包括Query/Update[22]、Hybrid/Quorum[23]、Zyzzava[24]、Zeno[25]、Zzyzx[26]等。针对PBFT算法在主节点发生拜占庭故障情况下,系统性能降低甚至丧失活性（活性是指在有限的时间内,分布式系统会对请求做出回复）的问题,出现了Aardvark[27]、Spinning[28]、Prime[29]、RBFT（Redundant Byzantine Fault Tolerance）[30]等共识算法,对拜占庭错误场景进行优化,减轻拜占庭主节点对系统的安全性和活性的影响。2018年,Abraham、Gueta 和Malkhi提出了Hot-Stuff算法[31],利用门限签名、并行流水线处理和线性视图转换等技术改进PBFT,极大提高了分布式共识算法的效率。此外,Golan-Gueta 等提出的可扩展拜占庭容错协议（Scalable Byzantine Fault Tolerance, SBFT）[32]主要解决拜占庭容错协议在应用到区块链中的去中心化和扩容问题,SBFT也使用门限签名技术降低通信复杂度以及其它节点验证消息时的计算开销。
上述经典分布式算法均假设网络模型为同步或者部分同步网络,2016年MILLER等提出了HoneyBadger BFT[33],该算法是首个实用的异步BFT类非确定性共识算法,可以在没有任何时间假设的前提下保证系统活性,能够在分布于广域网的上百个节点中每秒对上万笔交易达成共识。2018年,Abraham等提出了验证的异步拜占庭一致算法（Validated Asynchronous Byzantine Agreement, VABA）[34],VABA基于随机预言模型,在每次共识过程中采用多个并行的领导者提议,并从中随机选取一个作为最终结果,从而有效抵御适应性敌手的攻击。
随着区块链技术的兴起,共识机制也进入了区块链时代,已有的经典分布式共识算法被应用于区块链中,针对区块链系统对共识算法的需求,一系列用于区块链的共识算法陆续出现。
1.2 区块链共识算法
区块链共识算法主要包括证明类共识算法POX和POX+BFT混合共识。其中,证明类共识算法即POX类共识算法,利用自身具有的某种资源对区块链记账权进行竞争。例如,在基于工作量证明机制（Proof of Work,PoW）的共识算法中,节点利用自身算力资源竞争记账权,典型算法包括经典算法包括比特币[35]、以太坊[36]、Bitcoin-NG[37]等。这类算法存在算力浪费、交易吞吐量低、交易延迟高等缺陷,并可能面临双花攻击和自私挖矿等安全问题;而在基于股权证明机制（Proof of Stake,PoS）的共识算法中,节点利用自身股权（代币）竞争记账权,主要运行于匿名的点对点（P2P）网络中,一般具有加密货币的激励机制且去中心化程度较高,典型算法包括Peercoin[38]、DPOS[39]、Nextcoin[40]、Casper TFG[41]、Ouroboros[42]等。POX+BFT混合类共识将PoX与经典BFT类算法组合起来取长补短,吸取前者高扩展性、低消息复杂度的优点以及后者低交易时延、高交易吞吐量的优点,从而提高区块链性能。经典方案包括Tendermint[43]、peerCensus[44]、ByzCoin[45]、Algorand[46]、Casper FFG[47]、Thunderella[48]。
共识算法种类繁多、性能各异,在应用于SDN多控制器共识中如何选择、如何部署是亟待研究的一个问题。
表1对共识算法进行了汇总,对各种共识算法的容错能力、去中心化程度等特性进行了展示,在选择共识算法时应根据应用场景需求,结合共识算法的多项特性进行权衡。例如,在为SDN网络的分布式控制器集群选择共识算法时,应该考虑到SDN网络对于安全、性能、可扩展性等的要求,选择或重新设计出最适应需求的共识算法。
Table 1
表1
表1共识算法汇总表
Table 1
| 分类 | 名称 | 提出年份 | 拜占庭容错 （容错比例） | 去中心 化程度 | 交易处 理效率 | 是否需 要代币 | 区块链应用场景 |
|---|---|---|---|---|---|---|---|
| 经典分布式共识 | Paxos[20] | 1989 | 否（< ） | 低 | 高 | 否 | 联盟链/私有链 |
| Raft[21] | 2013 | 否（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| PBFT[12] | 1999 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| QU[22] | 2005 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| HQ[23] | 2006 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| Zyzzyva[24] | 2007 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| Zeno[25] | 2009 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| Zzyzx[26] | 2010 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| Aardvark[27] | 2009 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| Spinning[28] | 2009 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| Prime[29] | 2011 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| RBFT[30] | 2013 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| Hot-Stuff[31] | 2018 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| SBFT[32] | 2018 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| HoneyBadger[33] | 2016 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| VABA[34] | 2018 | 是（< ） | 低 | 高 | 否 | 联盟链/私有链 | |
| 区块链共识算法 | 比特币[35] | 2009 | 是（< ） | 高 | 低 | 是 | 公有链 |
| 以太坊 [36] | 2014 | 是（< ） | 高 | 低 | 是 | 公有链 | |
| Bitcoin-NG[37] | 2016 | 是（< ） | 高 | 低 | 是 | 公有链 | |
| Peercoin[38] | 2012 | 是（< ） | 高 | 较高 | 是 | 公有链 | |
| DPoS[39] | 2013 | 是（< ） | 中 | 较高 | 是 | 公有链 | |
| Nextcoin[40] | 2013 | 是（< ） | 高 | 较高 | 是 | 公有链 | |
| Casper TFG[41] | 2015 | 是（< ） | 高 | 较高 | 是 | 公有链 | |
| Ouroboros[42] | 2017 | 是（< ） | 高 | 较高 | 是 | 公有链 | |
| Tendermint[43] | 2014 | 是（< ） | 中 | 较高 | 是 | 公有链 | |
| peerCensus[44] | 2016 | 是（< ） | 中 | 较高 | 是 | 公有链 | |
| ByzCoin[45] | 2016 | 是（< ） | 中 | 较高 | 是 | 公有链 | |
| Algorand[46] | 2016 | 是（< ） | 中 | 较高 | 是 | 公有链 | |
| Casper FFG[47] | 2017 | 是（<） | 中 | 较高 | 是 | 公有链 | |
| Thunderella[48] | 2018 | 是（< ） | 中 | 较高 | 是 | 公有链 |
新窗口打开|下载CSV
2 SDN多控制器共识研究现状
软件定义网络SDN是由美国斯坦福大学CLean State课题研究组提出的一种新型网络创新架构,是网络虚拟化（Network Functions Virtualization,NFV）的一种实现方式。SDN概念是由两种互相补充的方案来驱动：一是IETF提出转发和控制元素分离（ForCES）[49],其侧重于用灵活的硬件组件构建转发模块;二是McKeown等提出的OpenFlow[50],侧重于在现有网络上构建用于试验新协议的网络基础平台。这两者在数据路径构造、协议灵活性以及协议粒度等方面存在差异,但是其核心都是将控制平面与数据平分离,将控制功能移至逻辑集中的控制平面,从而数据平面设备只需要简单的可编程网元。SDN将传统网络中的控制和转发功能分离,其控制平面通常由多个控制器组成,每个控制器控制不同的可编程网元。不同控制器之间,利用分布式系统的共识算法实现网络状态信息复制,从而保证各控制器中存储的网络状态信息的一致性,抵御潜在的控制器崩溃故障或拜占庭故障。2.1 SDN多控制器CFT类共识机制
现有SDN多控制器共识设计多采用控制器崩溃故障容错类共识算法,可分为强一致性算法或最终一致性算法。其中,强一致性共识算法可以获得最新的网络状态信息,但同步延迟高,而最终一致性共识算法虽然具有较低的同步延迟,但可能难以得到最新更新的网络状态信息。当前以ODL （OpenDayLight）[51]、ONOS（Open Network Operating System）[52]为代表的控制器集群架构主要是基于Paxos变形算法（如Raft等）,通过选取Leader节点和Follower节点,由Leader节点向Follower节点通告信息而达到全网状态的一致,属于强一致。强一致性协议使控制器虽然同步延迟大,但相比于最终一致性协议,更有利于获取最新的网络状态信息。例如Onix[53]和GRACE[54]利用Paxos实现多个控制器之间的网络状态复制,ODL Clustering多控制器架构和ONOS利用Raft共识协议实现多控制器之间的网络状态复制,而Ravana则采用更强的一致性保证[55]。最终一致性协议使控制器具有较低的同步延迟,但相对于强一致性而言,可能无法获取最新的网络状态信息。DISCO[56]基于面向消息的通信总线,为广域网和受限网络提供了分布式控制平面。控制器管理自己的网域,并基于AMQP（Advanced Message Queuing Protocol）与其它控制器进行通信。HyperFlow[57]利用发布-订阅消息传递实现多个控制器之间的网络状态复制。另外,LegoSDN[58]侧重于解决由于软件错误导致的控制器宕机故障。Akella等人[59]解决了带内网络的可用性问题并集合了泛洪、全局快照等分布式系统概念。Muqaddas等[60]对运行Raft共识协议的多个控制器之间的流量进行了量化,并总结出控制器间的流量规模随着网络规模的增长而增长的关系。
图1
新窗口打开|下载原图ZIP|生成PPT图1SDN多控制器CFT类共识机制研究进展
Fig.1Research progress of CFT consensus mechanism in SDN multi-controller layer
Yang Zhang[61]等针对多控制器间的Raft共识协议,提出控制器之间的共识执行依赖于数据平面进行通讯,而数据平面又依赖控制平面建立规则来实现可编程网元之间的数据包转发,这样的循环依赖将无法保证控制器之间的全连接,并提出了由此产生的两种错误场景,即主节点频繁更换、无法选出主节点以及相应的解决办法。Ermin Sakic[62]等则对集群的性能（响应时间和可用性）进行了研究,提出集群规模越大,则集群的最坏响应时间越低、系统可用性越高。此外,其还提出了一种watchdog机制,用于控制器集群发生软件故障时的快速恢复。
Venancio等 [63]针对单一集中控制器在可用性和可扩展性方面存在的问题,以及多控制器维护一致性易增加网络负载的问题,提出了一种基于虚拟网络功能VNF（Virtual Network Function）的共识机制,该机制在控制器间利用Paxos实现强一致性。图 1展示了近年来SDN多控制器CFT类共识机制的研究进展,早期较为知名的控制层面设计主要采用CFT类共识,后续的众多研究针对控制层面共识问题的安全以及性能问题进行探讨。
2.2 SDN多控制器BFT类共识机制
多控制器之间的不一致性严重影响着SDN应用的性能,一致性越差则应用性能越差[64],并且还会导致严重问题如转发环路、黑洞（black holes）、网络孤立与不可达等问题[65],因此分布式控制平面的共识机制是关乎SDN网络安全性以及性能的关键技术,已经受到了越来越多的关注。前面所分析的多控制器共识算法仅能抵御CFT类故障,而无法应对控制器或交换机的恶意行为即BFT类故障,并且当攻击者劫持Leader后很容易操纵网络[66]。为此,近年来研究重点转移到在SDN控制平面中引入BFT类共识机制[68,69,70,71,72,73,74,75,76,77],这类机制多是在多控制器间引入BFT类共识算法,但直接应用BFT共识会加重控制器间流量负载、扩展交换机功能、增加SDN控制平面压力等。为此,当前研究逐渐向自适应一致性机制（Adaptive Consistency）转变[67]。2014年,Li等[68]针对集中控制面存在的安全挑战,提出了一种基于BFT的安全SDN架构,其每个交换设备由多个基于云的控制器实例进行管理,并基于该架构设计了一种有效的控制器分配算法。2016年,ElDefrawy等[69]开发了一个能够抵御控制平面和数据平面发生拜占庭故障的弹性SDN控制器层原型,其在开源SDN模拟软件上的实验结果表明：BFT机制降低了控制器处理流表的性能,在有4个控制器节点的情况下可以容忍1个节点发生BFT类故障。2017年,Mohan等[70]针对直接采用BFT类机制容易导致交换机过载的问题（每个交换机需要映射到3f +1个控制器来抵御f个控制器故障）,提出了一种主备控制器映射方案,在该方案中每个交换机只需要映射到f +1个主控制器和f个备份控制器即可抵御f个控制器的拜占庭攻击。2018年,Sridharan等[71]针对过载问题则提出了一种基于博弈论的高效恶意控制器检测方法,该方法随机选择交换机来检查转发规则的一致性,并将其建模为Stackelberg博弈问题,通过解决对应优化问题来获取有效的随机策略。此外,Yuan等[72]针对恶意交换机通过给控制器发送错误信息而误导控制器的问题,设计并实现了一个可以支持BFT共识机制的控制原型系统,该系统可以容忍交换机故障,确保控制器输入的正确性。2018年,Sakic等[73]提出了一种能够容忍不可用性和拜占庭式故障的自适应SDN控制平面框架MORPH,通过将分布式SDN控制平面的控制器实例建模为一组复制状态机（Replicated State Machine, RSM）来处理拜占庭式故障,能够区分和定位故障控制器实例,并在检测到故障后适当地重新配置控制平面来重构控制器与交换机之间的连接。此外,Sakic等[74]认为基于RSM 的BFT机制易引入额外开销,导致其可扩展性较差,为此提出了一种“基于组的一致执行”方法来提升BFT类分布式SDN控制面的全局吞吐量。同时,Sakic等[75]针对BFT类共识中控制器间信息传输及消息识别匹配消耗过多CPU负载、引发额外延迟、增加重配置时间等问题,提出了一种基于P4的P4BFT机制,引入处理节点执行匹配功能,并通过优化处理节点的选择来减少控制平面负载和重配置时间。
Zhi等[76]提出了BQSV（Byzantine Quorum System with Verification function）方法,结合SDN控制层集群和Byzantine Quorum系统,确保集群在存在恶意控制器的情况下也能提供正确的网络拓扑视图。最近,Moazzeni等[77]提出了一种可靠容错的分布式SDN方法即BIRDSDN（Byzantine‐Resilient Improved Reliable Distributed Software‐Defined Networks）,该方法在控制器集群直接采用组通信方式来检测CFT和BFT类故障,并引入快速修复机制选择新的控制器来接管受影响的交换机。图 2展示了近年来SDN多控制器BFT类共识机制的研究进展,研究者们将BFT类共识机制引入控制层面,并针对采用BFT类共识的控制层的安全或者性能问题进行讨论,并提出了众多具有自适应性的解决方案,2.3节对该类自适应性多控制器共识机制进行了更加深入的介绍。
2.3 SDN自适应多控制器共识机制
当前多控制器的共识机制在实际部署中仍以RAFT为代表的CFT类共识机制为主,无法应对控制器与交换机的BFT类故障。改进型的BFT类共识机制则存在可扩展性问题,增加了控制平台的负载和控制器的处理时延,严重影响了上层应用的性能（依据文献[60]的研究,相关性能约降低2倍）。自适应性多控制器共识机制旨在基于SDN网络具体需求,结合实时状态适应性地对相关网络配置进行调整,从而改善控制层引入BFT类共识机制后存在的系统可扩展性差以及吞吐量低等问题。图2
新窗口打开|下载原图ZIP|生成PPT图2SDN多控制器BFT类共识机制研究进展
Fig.2Research progress of BFT consensus mechanism in SDN multi-controller layer
表 2对具有自适应性的SDN控制器层BFT类共识机制设计方案进行了汇总,针对分析了其研究动机和主要思想。
Table 2
表2
表2自适应SDN多控制器BFT类共识机制对比
Table 2
| 设计方案 | 研究动机 | 主要思想 |
|---|---|---|
| MORPH[73] | 前期多控制器BFT共识方面的研究缺少对自适应控制器-交换机连接重新分配过程的分析,也没有考虑当控制器发生不同类型故障时分配策略的差异性设计。 | 当检测到控制器发生拜占庭故障或非拜占庭故障时,采取不同的交换机-控制器适应性重分配策略,并在分配时考虑当前分别处于正常和故障状态的控制器数量、控制器的最大延迟和能力等实时条件以达到最佳的网络配置从而降低通信开销。 |
| BFT Protocols for Heterogeneous Resource Allocations in Distributed SDN Control Plane[74] | 前期的基于RSM的多控制器BFT共识机制设计的方法可扩展性较差,需要引入更有效的方法提高分布式SDN控制平面的总体吞吐量。 | 在MORPH的基础上,提出“基于组的一致执行分离”方法,适应性地为每个交换机分配控制器分组,考虑了当前各控制器通信延迟、执行能力等实时条件,所提议的模型与最先进的方法相比,在系统响应时间和通信开销方面明显减少。 |
| P4BFT [75] | 多控制器BFT类共识中存在着控制器间信息传输及消息识别匹配消耗过多CPU负载、引发额外延迟、增加重配置时间、对交换机具有专用功能要求使得部署灵活性差等问题。 | 提出一种基于P4的P4BFT机制,引入处理节点（processing node）执行匹配功能,来减少SDN控制器向其目标配置交换机所传输的消息总量;并通过考虑交换机处理能力和上限重构延迟等实时约束来优化处理节点的选择,从而减少控制平面负载和重配置时间。 |
| BIRDSDN [77] | 当前针对控制器-交换机映射重配置的研究,缺少对实时因素的考虑,导致交换机重新配置的时间长,无法为交换机选择最可靠的控制器,缺少针对多控制器层节点发生崩溃故障和拜占庭故障的快速检测和恢复方案。 | 在进行控制器-交换机映射更新时,适应性地考虑了通信链路故障概率、拓扑、负载、距离和延迟等实时因素,以使交换机能够分配到最可靠的控制器。 |
新窗口打开|下载CSV
3 多控制器共识机制的问题与解决方案
3.1 多控制器共识机制存在的问题
控制器之间需要对控制器本地网络事件、控制器向数据平面下发的流表、网络拓扑等数据进行共享,使得各控制器能够了解全网视图,并基于此完成正常的网络控制功能。在当前的众多控制器集群设计中,由控制器运行共识协议对网络状态数据达成共识,使得各节点按照相同顺序接收（执行）其所接收到的消息中包含的网络状态更改动作,即保证各控制器了解到的全网视图的相同性,并对参与共识的部分宕机节点或拜占庭节点实现具有容错性,从而实现具有高安全性和活性的数据共享（同步）。共识机制种类众多、特性各异,但并不存在一个适用于任何场景的最佳共识机制,因此在为控制器层的数据共享选择共识机制时,应根据待共享数据的需求,在安全性、可扩展性、吞吐量、时延等性能指标之间进行权衡。
然而,若要沿用当前的“控制器节点即共识节点”的设计,不论采用何种共识协议,都存在着如下问题：
（1）共识网络的部署灵活性受限：共识机制能够保障在各节点的数据共享过程,系统对参与共识的部分节点具有宕机容错或者拜占庭容错能力,共识节点数量的增加有利于增强共识的安全性,能够容忍更多数量的节点发生拜占庭故障,但也会导致系统性能的降低,因此可以考虑为安全性要求更高的共享数据部署更多的共识节点。然而,由于控制器层控制节点的数量固定且数量较少,如果由控制节点运行共识协议,难以灵活控制共识网络的节点数量。
（2）控制器运行共识机制的额外开销：控制器作为SDN网络的枢纽,需要承担路由决策、网络管理等众多任务,当采用安全性较高但占用计算资源较大的多阶段共识机制来完成控制器之间的数据共享时,将会大大增加控制器负载,甚至影响控制器的路由决策等固有功能的顺利执行。
3.2 基于区块链的控制器层数据共享第三方服务
针对3.1节中提到的问题,可考虑利用第三方系统来完成待共享网络数据的收集和同步工作,从而为SDN网络控制层提供数据同步服务。该服务作为保障SDN网络控制层正常运行的关键服务,要求第三方系统能够保证其所提供的数据共享服务的安全、可信性,即不仅能够保障单点故障、部分节点故障下服务的正常提供,保障各控制器能够及时掌握正确且相同的网络视图,还能为服务建立去中心化的信任基础。区块链技术的出现为解决SDN网络控制层数据共享的安全可信问题提供了一种新的思路,由于区块链具有去中心化、去信任化、不可篡改、可追溯、公开透明、集体维护等特性,因此其能够作为第三方完成待共享网络数据的收集、共识（包括序号分配、交互、序号确认等阶段）、响应工作,解决上述控制层数据共享存在的问题。
SDN控制器利用区块链系统作为第三方提供数据共享服务的流程图如图3所示,各控制器将网络数据打包成数据共享请求,并发送至区块链系统中,由区块链主节点将一定数量的请求打包成区块,再依据所采用的共识机制的交互流程,在各区块链节点之间达成对区块的共识,最终由区块链节点将达成共识的区块发送至各个控制器,各控制器学习区块中包含的网络信息,了解其余控制器的网络事件以及下发的流表命令等信息。
图3
新窗口打开|下载原图ZIP|生成PPT图3SDN控制器数据共享流程图
Fig.3Flow chart of SDN controller data sharing
上述区块链系统能够为SDN网络控制层提供安全、可信、部署灵活的数据共享服务,该设计的具体优势表现在如下几点：
（1）安全可靠：对于运行区块链共识算法的区块链系统,安全性主要体现在可以抵御短距离攻击、长距离攻击、币龄累积、女巫攻击等安全攻击;对于运行经典分布式共识算法的区块链系统,安全性主要体现在系统对节点故障的容错能力,即当部分节点自身发生故障或受到外界恶意劫持时,区块链系统仍然能够作为可靠的第三方向SDN控制器层提供可靠的数据共享服务。
（2）可信：在区块链系统中,多个参与方共同构建与维护区块链账本,区块是否能达成共识由参与共识的节点共同决定,而不是集中在少数几个节点上。区块链作为数据共享服务的第三方,能够保障自身系统的（部分）去中心化、（部分）去信任化。
（3）部署灵活性、高可伸缩性：控制器层中不同类型的待共享数据对于数据共享服务提供者的安全性、可扩展性、吞吐量、时延等性能指标的要求可能不同。利用当今区块链的多链技术,可方便地部署节点数量不同、运行共识机制不同的子链,从而为需求不同的网络数据提供定制化的数据共享服务。区块链作为数据共享服务的第三方,能够保障自身系统部署和运维的灵活性、高可伸缩性。
（4）便于监督控制器异常行为：区块链的分布式存储和独特的链式数据存储结构也能够保障所存储数据的不可篡改性、可追溯性,当控制器在数据共享过程中表现出恶意行为时,便于通过区块链账本进行可信的责任追究。另外,利用当前的智能合约技术,也方便对账本数据进行实时监控,针对可能威胁SDN网络安全的控制器数据共享行为,触发一系列的安全防御和及时恢复操作。
4 基于区块链的SDN网络可信基础设施
4.1 可信SDN网络架构
SDN网络作为一种重要的网络架构,其应用层、控制层、数据层均受到众多安全挑战[78],对控制器、交换机、网络管理员等实体的行为也缺乏监管机制,即当网络实体出现异常行为时难以做到及时检测和恢复,SDN网络架构难以对其所提供的网络服务的安全可信提供保障。区块链技术的出现不仅为控制器层的数据共享提供了解决方案,也为解决整个SDN网络架构中的安全可信问题提供了一种新的思路。利用区块链的去中心化、去信任化、不可篡改、可追溯、公开透明、集体维护等特性,可以用其为分布式控制器层构建起信任基础。如图4所示,可将区块链作为SDN网络的可信基础设施,为SDN网络提供各种可信任的安全服务,4.3节对可信区块链基础设施适合采取的部署结构进行了介绍。
图4
新窗口打开|下载原图ZIP|生成PPT图4可信SDN网络架构
Fig.4Architecture of trusted SDN network
第一层是区块链设施层,包括共识机制、区块链数据结构、P2P通信、智能合约、激励机制、密码学、区块索引存储等,由不同节点共同维护区块链账本。
第二层是区块链服务层,将不同区块链服务进行打包,向上层提供简单易用的接口,包括的服务有数据共享服务、身份认证服务、网络管理员行为记录和追溯服务、控制器行为记录和追溯服务、BaaS等,可根据SDN网络可信需求的发展提供更多的服务。3.2节对这些可信安全服务进行了更加详细的介绍。
第三层是SDN网络层,控制器在加入网络时,通过区块链进行身份认证与注册,不同控制器之间通过区块链对网络拓扑等数据进行共享。通过区块链的控制器行为记录和追溯服务,对于控制器集群中部分节点的恶意行为能够快速找到错误源,并进行矫正。通过网络管理员行为记录和追溯服务,方便进行网络管理员行为监管以及责任追究。
最上层是SDN应用层,由于是建立在安全可信SDN网络上的,用户、应用服务提供商,以及控制器和交换机等网络实体的身份都能够被验证,从而保障服务的安全可信任性。
4.2 可信SDN安全服务
利用区块链技术可为SDN网络构建信任基础设施,4.1节对该信任设施的架构进行了总体介绍,该节对架构中区块链服务层能够为SDN网络提供的可信安全服务进行更加详细的描述,并对各类服务的相关研究进行了介绍,3.2节中已对数据共享服务进行了详细介绍,这里不再赘述。（1）身份认证服务
当SDN网络管理员需要对区块链系统或者控制器层进行相关操作,如对区块链系统进行数据访问以及合约部署,对控制器层进行状态查询或系统参数配置等,该类操作涉及数据保密性以及系统安全,因此需要对管理员身份进行认证,从而实现数据保护和行为审计。另外,控制器以及交换机作为SDN网络中的重要设施,其安全接入关乎SDN网络的正常运行和安全问题,因此需要对其身份进行认证,从而实现对SDN网络的安全保护。
传统的PKI能够为身份认证提供服务,但近年来,针对PKI的攻击频繁发生,例如被劫持的CA颁发恶意证书,吊销的证书仍然受到用户信任。区块链系统能够为身份认证提供去中心化的PKI服务,从而杜绝众多针对传统PKI的网络攻击,利用区块链的公开透明性也能够保障公开证书的可验证性。
（2）BaaS
智能合约为用户提供编程接口,使用户能够将实现各类复杂业务的逻辑以智能合约代码的形式方便地部署在区块链系统上,而无需重新修改区块链系统底层代码,从而提供即时的区块链服务,即BaaS（Blockchain as a Service）。
SDN控制器层的网络管理员可以根据新的业务需求编写智能合约并部署,由合约对区块链中记录的数据进行监控,并触发一系列针对区块链或SDN控制器层的操作和服务。已有研究已经讨论过如何将即时区块链服务用于应对针对SDN网络的安全攻击问题,例如,ZA El Houda[79]等提出了一个名为Cochain-SC的基于区块链的架构,该架构针对典型DDoS攻击,设计了两层DDoS攻击抵御方案（域内和域间DDoS抵御）,利用以太坊的智能合约,促进SDN不同域的控制器之间进行协作,减少跨域转发数据包的成本,避免放大攻击流量,实现就近阻止攻击。
（3）行为记录和追溯服务
在SDN网络中,控制器、交换机以及网络管理员等实体的行为影响着SDN网络的整体运行和安全问题,利用区块链技术能够为SDN网络提供对这些实体的行为记录和追溯服务,网络管理员行为记录和追溯能够提供对网络管理员的行为监督和责任追查服务;控制器行为记录和追溯服务能够保证控制器发布的流表规则的有效性、可追溯性、不可篡改性,从而保障SDN网络的安全可信。已有研究[80]针对分布式SDN中的流表验证问题,提出了一种基于区块链技术的新架构DistBlockNet,该架构利用区块链技术更新流表,从而可对流规则表的版本进行安全验证,以增强物联网的安全性、灵活性和可扩展性。
另外,未来投入使用的SDN架构应由各运营商共同维护,因此涉及运营商之间的相互信任和费用审计问题,基于区块链提供的行为记录和追溯服务,能够方便快捷地解决SDN网络在多运营商参与不可信环境下的信任问题和审计问题。已有的一些研究已经讨论过将区块链技术用于解决该问题,研究[81]讨论了SDN体系结构中存在的安全挑战,并建议在SDN中部署区块链用于构建多运营商之间的相互信任,并提高数据标准化和抗故障能力;研究[82]在区块链机制的基础上,通过在数据平面（交换机层）添加监控元,并采用ECDSA签名算法和分布式密钥生成协议,设计了一个基于区块链的SDN控制器分布式审计系统,为多运营商参与的控制器集群提供无第三方参与的费用记录。
在上述分析中提到的研究都致力于将区块链技术应用于SDN网络中的不同部分,但都并没有考虑到将区块链系统作为基础设施,为SDN网络提供全方位的安全可信服务。综上分析,可以看到利用区块链作为安全可信基础设施,能够有效提升SDN应对各种网络问题的抵御能力,提升控制器在节点管理、状态监控、设备配置、用户管理、网络业务等方面的安全能力,从而为上层应用提供一个安全可信的环境。
4.3 可信区块链基础设施部署
区块链能够作为基础设施为SDN网络提供全方位的服务,但在实际部署中,需要考虑区块链的性能瓶颈和可扩展性问题,另外,不同服务对于安全性、可扩展性、交易处理能力等的要求也不同。为此,如图5所示,可选择多链结构作为安全可信区块链基础设施的部署结构,每条子链负责一种服务,不同子链之间的交易处理、数据存储、区块共识相互隔离,由主链负责子链之间的跨链通信,从而实现服务之间的互相隔离且可交互。不同的子链可以部署在完全互不相交的节点集合上,也可以部署在相交的节点集合上,即同一节点可以负责维护不同的子链,第二种部署方式实际为金链盟开源工作组协作打造的联盟链平台FISCO BCOS[83]的多群组设计思想,在保障不同子链之间隔离性的同时,降低了系统的运维复杂度。可为负责不同服务的子链选择不同的共识机制,并根据需求设计不同的机制以提高区块链性能;当SDN网络的安全需求增加时,只需扩展新的子链即可提供新的服务,使该架构具有高可扩展性。图5
新窗口打开|下载原图ZIP|生成PPT图5区块链部署结构——多链
Fig.5Deployment architecture of blockchain system—MultiChain
5 结论与展望
本文对SDN网络中的用于实现控制器之间数据共享的共识机制设计进行了综述,本文提出的基于SDN可信基础设施能够为SDN网络提供控制器间数据共享等多种安全可信服务,但将该设施进行落地应用时,仍然存在一些挑战。例如,由于当前的共识算法种类众多、特性各异,且并不存在一个适用于任何场景的共识算法,因此需要针对SDN网络对于不同服务的需求,在安全性、可扩展性、吞吐量、时延等指标之间进行权衡,对区块链节点间运行的共识算法、区块链节点数量等系统部署细节进行实验分析和具体决策。另外,由于当前的用于SDN网络控制器之间沟通联系的东西向协议并没有定义统一标准,因此在上链数据的数据结构设计、区块链相关操作设计等方面需要考虑适用性。利益冲突声明
所有作者声明不存在利益冲突关系。参考文献 原文顺序
文献年度倒序
文中引用次数倒序
被引期刊影响因子
[N].
[本文引用: 1]
[J].
[本文引用: 1]
[C].
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 2]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[C]//
[本文引用: 2]
[EB/OL].
URL [本文引用: 1]
[EB/OL].
URL [本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[C]//
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 2]
[C]//
[本文引用: 2]
[J].
[本文引用: 2]
[C]//
[本文引用: 2]
[C]//
[本文引用: 2]
[C]//
[本文引用: 2]
[C]//
[本文引用: 2]
[C]//
[本文引用: 2]
[C]//
[本文引用: 2]
[J].
[本文引用: 2]
[C]//
[本文引用: 2]
[EB/OL].2018. http://arxiv.org/abs/1803.05069.
URL [本文引用: 2]
[EB/OL].2018. http://arxiv.org/abs/1804.01626.
URL [本文引用: 2]
[C]//
[本文引用: 2]
[EB/OL]. 2018. http://arxiv.org/abs/1811.01332
URL [本文引用: 2]
[EB/OL].2008. http://bitcoins.info/bitcoin.pdf.
URL [本文引用: 2]
[EB/OL].2014. https://whitepaperdatabase.com/wp-content/uploads/2017/09/Ethereum-ETH-whitepaper.pdf.
URL [本文引用: 2]
[C]//
[本文引用: 2]
[EB/OL].
URL [本文引用: 2]
[EB/OL].2018. http://iang.org/papers/EOS_An_Introduction.pdf.
URL [本文引用: 2]
[J].
[本文引用: 2]
[EB/OL].2018. https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/.
URL [本文引用: 2]
[C]//
[本文引用: 2]
[EB/OL].2014. https://tendermint.com/static/docs/tendermint.pdf.
URL [本文引用: 2]
[C]//
[本文引用: 2]
[C]//
[本文引用: 2]
[C]//
[本文引用: 2]
[EB/OL].2017. http://arxiv.org/abs/1710.09437
URL [本文引用: 2]
[C]//
[本文引用: 2]
.2004. http://tools.ietf.org/html/rfc3746
URL [本文引用: 1]
[J].
[本文引用: 1]
[EB/OL].2017. http:// www.opendaylight.org/.
URL [本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 2]
[C]//
[本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[C]//
[本文引用: 1]
[J].
DOI:10.1016/j.comnet.2013.12.004URL [本文引用: 1]
Software-Defined Networking (SDN) is a new network technology that decouples the control plane logic from the data plane and uses a programmable software controller to manage network operation and the state of network components. In an SDN network, a logically centralized controller uses a global network view to conduct management and operation of the network. The centralized control of the SDN network presents a tremendous opportunity for network operators to refactor the control plane and to improve the performance of applications. For the application of load balancing, the logically centralized controller conducts Real-time Least loaded Server selection (RLS) for multiple domains, where new flows pass by for the first time. The function of RLS is to enable the new flows to be forwarded to the least loaded server in the entire network. However, in a large-scale SDN network, the logically centralized controller usually consists of multiple distributed controllers. Existing multiple controller state synchronization schemes are based on Periodic Synchronization (PS), which can cause undesirable situations. For example, frequent synchronizations may result in high synchronization overhead of controllers. State desynchronization among controllers during the interval between two consecutive synchronizations could lead to forwarding loops and black holes. In this paper, we propose a new type of controller state synchronization scheme, Load Variance-based Synchronization (LVS), to improve the load-balancing performance in the multi-controller multi-domain SDN network. Compared with PS-based schemes, LVS-based schemes conduct effective state synchronizations among controllers only when the load of a specific server or domain exceeds a certain threshold, which significantly reduces the synchronization overhead of controllers. The results of simulations show that LVS achieves loop-free forwarding and good load-balancing performance with much less synchronization overhead, as compared with existing schemes. (C) 2014 Elsevier B.V.
[EB/OL].2014. http://www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf.
URL [本文引用: 1]
[J].
DOI:10.1109/JSAC.2018.2871309URL [本文引用: 1]
[J].
DOI:10.1109/TCC.2014.2355227URL [本文引用: 2]
[C]//
[本文引用: 2]
[C].
[本文引用: 2]
[C]//
[本文引用: 2]
[J].
DOI:10.1109/TNSM.2018.2822668URL [本文引用: 2]
[J].
DOI:10.1109/JSAC.2018.2869938URL [本文引用: 3]
[C]//
[本文引用: 3]
[C]//
[本文引用: 3]
[C]//
[本文引用: 2]
[J].
[本文引用: 3]
[C]//
[本文引用: 1]
[J].
DOI:10.1109/Access.6287639URL [本文引用: 1]
[J].
[本文引用: 1]
[C]//
[本文引用: 1]
[C]//
[本文引用: 1]
[EB/OL]. http://fisco-bcos.org/zh/.
URL [本文引用: 1]
