作为未来网络研究的热点领域，软件定义网络（software-defined networking，SDN）正凭借其易管理、可编程等优势，受到业界的广泛关注^[1-2]. 在航空领域，为了满足大规模、功能各异的航空集群^[3]平台间的通信需求，Thangamurugan等^[4-6]将SDN应用于机载网络的构建中，提出软件定义机载网络的概念.

与传统的分布式网络架构相比，SDN网络的控制与管理是由逻辑集中的控制平面负责. 这种方式虽然可以大大提升网络自动化管理和控制能力，但导致了网络对控制平面的依赖性. 在航空环境中，网络环境更加复杂多变，高对抗战场环境不仅使得节点故障概率更高，同时受节点移动性和链路不可靠性等因素影响，控制器之间难以像地面有线网络一样稳定、可靠地交互信息，这给控制平面的设计提出了较大挑战. 其中，控制器故障将直接导致网络节点无法处理网络数据流并上传自身状态信息，对网络性能的影响最大.

近年来，为了提高控制平面的健壮性，研究人员从控制器部署和交换机迁移2个方面，研究控制器故障恢复问题. 一类研究是在网络前期规划阶段，通过部署备份控制器的方式来增强控制平面的可靠性^[7-9]. 其中，Ros等^[7]提出针对控制器故障恢复的FTCP布局方法. 该方法通过部署冗余的控制器，实现控制器故障后的快速恢复. 备份控制器的确定方法仅仅针对网络拓扑固定的地面静态网络. 在机载网络环境下，由于控制器的故障检测具有时延限制，原有的备份控制器往往因为节点移动，难以满足网络需求. 另一类研究是在控制器布局确定之后，通过迁移故障域的交换机对网络进行弹性管控^[10-11]. Openflow1.4协议中增加了当控制器发生故障或超载情况下域内交换机向外迁移的机制. Hock等^[10]将距离和时延作为迁移的首要衡量因素，对迁移机制进行设计. 这类迁移的方法虽然可以在网络运行过程中对网络进行动态调整，但没有考虑控制器的恢复. 在机载网络环境下仅对故障域内节点进行迁移，不仅效率低、迁移代价大，而且增加了相邻控制器的负担，极易造成整个控制平面的失衡.

针对上述问题，本文将机载网络环境下的控制器故障恢复问题优化为控制节点的选举问题，提出分布式的控制节点选举（distributed controller node election，DCNE）算法. 为了保证故障恢复后的网络性能，综合考虑邻居节点密度、平均流请求量和控制器处理能力，计算选举权值. 为了实现DCNE算法在机载网络环境下的有效应用，考虑网络的拓扑动态变化、新节点加入等特征，提出依据节点状态传递和处理选举消息的选举算法.

笔者等^[12]已对航空集群环境下的多控制器架构及其部署问题进行研究，解决了网络的初始规划问题. SDN在航空集群环境下的应用示意图如图1（a）所示，层次型的多控制器架构形成了逻辑集中控制式的机载网络. 在多控制器部署完成后，网络被分成多个控制域，每个控制域内有一个控制器，负责管理域内网络数据流. 本文只对该控制器架构进行简要概念描述，重点研究该架构下单个控制器的故障恢复问题.

航空集群每个平台均应部署一个控制器，但在相同时间一个域内仅有一个控制器保持工作. 这不仅为控制器故障恢复提供了物理硬件基础，而且有利于网络根据拓扑、流量的变化灵活选取节点作为控制器，实现对网络的弹性管控. SDN在机载网络中实际应用时，集中式网络控制（即SDN方式）和分布式网络控制（即传统网络传输方式）是共存的. 在集中式网络控制不可用的情况下，分布式网络控制方式能够使节点不依赖与控制器的信息交互，通过邻居节点间协商的方式，独立完成自身信息传输过程.

在上述场景及网络控制架构下，集中式网络控制下机载网络的局部拓扑示意图如图1（b）所示. 控制器C₁发生不可逆的故障，导致域A₁内的节点与控制器失连. 要研究的问题如下：在控制器发生故障导致集中式网络控制方式（即SDN方式）不可用的情形下，故障域内的节点如何基于传统的分布式网络控制方式，通过域内节点间的协商完成选择新的控制节点的选举.

考虑到本文首次采用集中式网络控制和分布式网络控制，描述航空集群环境下的SDN传输方式和传统机载网络传输方式. 为了避免概念上的疑义，针对本文研究问题，作出以下说明.

1）控制器为co-located部署方式，即控制器和交换机部署于网络同一节点，作为控制器使用时称为控制节点，否则称为传输节点.

2）在控制器选举过程中，相邻控制域内的节点可能参与到选举过程中，如进行选举消息的转发、网络连通性保证等. 为了对不同节点进行区分，用失控节点来表示与控制器失连的传输节点. 由于机载网络的特殊环境，传输节点可能由于移动性或者控制链路中断而导致集中式网络控制方式不可用，成为失控节点. 失控节点的判定在4.1节进行描述.

3）控制节点的选举是在集中式网络控制不可用的失控节点之间开展的. 基于分布式的网络控制方式，每个节点通过周期性地发送Hello消息和Ack-hello消息，可以获取邻居节点状态信息.

为了形式化描述本文算法，对于网络中任一失控的节点 ${v_i}$，假设其在一跳范围内的邻居失控节点集为 $S({v_i}) = \{ {v_1}, \cdots ,{v_j}\} $，满足 $D({v_i},{v_j}) \leqslant R$， ${v_j} \in $ $ S({v_i})$. 其中 $D({v_i},{v_j})$ 表示节点 ${v_i}$ 和 ${v_j}$ 间的距离，R为节点通信半径.

在集中式网络控制方式下的机载网络中，控制节点的位置不仅会影响到新流建立的时延，而且会直接影响到网络的配置、管理效率及可靠性等方面. 与利用全局网络状态信息（如全网拓扑、每个节点策略配置需求等）进行控制器部署位置决策不同的是，在控制器故障的情况下，每个节点基于分布式网络控制方式仅具有自身及邻居节点局部有限的状态信息. 为了保证控制节点位置的合理性和故障恢复后的网络控制性能，定义如下控制节点的评判参数.

1）邻居节点数量. 定义失控节点 ${v_i}$ 的邻居节点数量为 $N({v_i})$，则 $N({v_i}) = \left| {S({v_i})} \right|$. $N({v_i})$ 表示节点 ${v_i}$ 一跳范围内失控节点的集合. 在机载网络环境下，由于通信链路的不稳定性因素影响，节点的邻居节点数量越大，其一跳范围内失控节点的数量越多，选举该节点作为控制节点进行网络控制的开销与时延越少.

2）本地流请求总量. 考虑到网络中每个节点流表配置需求的不同，使用网络无故障时节点 ${v_i}$ 向所属控制器发送的平均PACKET_IN请求量 $l({v_i})$，近似描述该节点的流表配置需求^[13]. 由于网络流量的实时动态变化，采用网络无故障时PACKET_IN请求量的平均值，更能够反映节点的流表配置需求.

在控制器故障恢复后，必定会重新配置所属控制域内的节点流表，每个节点的 $l({v_i})$ 越大，表示该节点的流表配置需求越高. 为了表示节点 ${v_i}$ 及其邻居节点的流表配置需求总量，定义节点 ${v_i}$ 的本地流请求总量为

(1) $L({v_i}) = \sum\nolimits_{{v_j} \in S({v_i})} {l({v_j})} + l({v_i}).$

节点 ${v_i}$ 的本地流请求总量表示节点 ${v_i}$ 及其邻居节点的平均流请求总量. 在集中式网络控制下， $L({v_i})$ 越大，表示该节点一跳范围内节点的流表配置需求越高，该区域节点向控制节点发送的PACKET_I请求量越多. 选举该节点作为控制节点，能够保证控制节点部署于流配置需求高的区域，有利于提高网络的管控效率.

3）控制器容量. 参考文献[14]中控制器容量的测试方法，用平均流吞吐量 $C({v_i})$ 来表示节点 ${v_i}$ 所搭载的控制器容量，即该控制器能够处理的最大PACKET_IN请求量. $C({v_i})$ 越大，控制节点可管理的节点数量越多. 由于控制器容量不仅与网络硬件的处理能力有关，也与网络流的到达情形、网络业务的QoS需求等限制因素有关，在实际应用时很难有准确的值进行表示. 在航空集群环境中，受平台类型和载荷等因素的影响，各个平台搭载的软、硬件资源差异较大，仅考虑由该因素导致的控制器容量的不同.

综合考虑上述控制节点的评判参数，定义 ${v_i}$ 进行控制节点选举时的权值 ${\rm NW}({v_i})$ 为

(2) ${\rm NW}({v_i}) = {w_1} N({v_i}) + {w_2} L({v_i}) + {w_3} C({v_i}).$

式中： ${w_1}$、 ${w_2}$ 和 ${w_3}$ 为对应评判参数的权重系数.

因为各参数的计量单位不同，不能互相计算比较，需要进行规范化处理. 采取熵法来评估各参数的相对重要程度，综合得到每个节点进行选举的权值. 熵法计算的原则如下：在某一参数上取值相差越大，则它的相对重要程度越大，该标准所占的权重越大. 使用该方法来求解各参数的权重系数，根据节点 ${v_i}$ 及其邻居失控节点集 $S({v_i})$ 的参数值，权重系数的计算步骤如下.

1）用 ${p_m}({v_i}),m = 1,2,3$ 分别表示3个评判参数. 根据下式规范化每个参数值，某一参数 ${p_m}({v_i})$ 表示为

(3) ${p_m}({v_i}) = \frac{{{p_m}({v_i})}}{{{p_m}({v_i}) + \displaystyle\sum\nolimits_{{v_j} \in S({v_i})} {{p_m}(v{}_j)} }}.$

2）每个参数的熵求解方法为

(4) ${E_m} = - \frac{1}{{\ln \left| {S({v_i})} \right|}}\sum\nolimits_{{v_j} \in S({v_i})} {{p_m}} ({v_i})\ln {p_m}({v_i}).$

当 ${p_m}({v_i}) = 0$ 时， ${p_m}({v_i})\ln {p_m}({v_i}) = 0$.

3）根据式（4）可得，每个参数的权重求解方法为

(5) ${w_m} = \frac{{1 - {E_m}}}{{\displaystyle\sum\nolimits_{m = 1}^3 {(1 - {E_m})} }}.$

领导者选举算法作为分布式系统中一种比较经典的算法，被广泛应用在路由协调、总体控制、传感器协调、网关选举等无线网络环境^[15]. 领导者选举算法的核心思想是在一个由多节点构成的组群中，有效地选举出唯一的节点，作为整个组群的领导者，协调其余节点的正常工作.

在借鉴领导者选举算法相关研究成果的基础上，考虑到航空集群的特殊环境和控制节点位置对机载网络性能的影响，为了实现控制节点的选举，设计分布式的控制节点选举DCNE算法. 该算法的实现主要包括以下3个阶段：邻居状态的建立和维护、Election消息的传递和Controller信息的发布. 下面从这3个阶段依次对该算法进行描述.

在该阶段首先进行节点失控的判定：采用超时机制的故障检测方法^[16]，规定在集中式网络控制方式下，若一个传输节点连续3次请求没有收到控制节点的响应，则认为该节点处于失控状态.

在该状态下，失控节点基于分布式的网络控制方式，通过节点间周期性地发送hellow消息和Ack-hellow消息进行邻居节点间状态感知. 为了实现选举权值的计算，除必须的1跳路由维护信息外，hellow和Ack-hellow消息还应当包括该节点的邻居节点总数、多跳业务量和控制器容量等节点权值计算参数信息.

节点在检测到与控制节点失连后，不会立即发送Election消息. 这是因为受机载网络节点的高移动性和链路的不稳定性因素影响，在控制器可用的情形下可能出现部分传输节点失控的情形，在这种情形下进行控制节点的选举没有必要，会影响到网络业务的正常传输. 在控制器故障情形下，如果每个节点在检测到与控制节点失连后，都启动一轮选举进程，会导致选举算法的复杂度大大增加，网络负担加重. 针对上述情况，为了保证选举时失控节点的规模，避免多个失控节点同时发起选举，根据初始控制域内传输节点的分布及每个节点的流表配置需求，规定当失控节点的本地流请求总量 $L({v_i})$ 超过节点自身所搭载控制器容量的1/k时，该节点才能发送Election消息进行选举. 该指标为Election消息发送的起始条件，与邻居失控节点数量及其流表配置需求有关，综合考虑机载网络中传输节点与对应控制器的分布情况，本文设置 $k = 3$.

控制节点的选举是通过Election消息在网络中传递开展的，通过这种方式网络中失控节点的信息被收集计算并通知下一节点，最终在停止条件触发下Election消息停止传递，选出权值最大的节点作为控制节点. Election消息除包含发起节点ID号和NW值，控制节点的ID号、NW值和容量C外，还应该包含一个接受分组（receive array，RA）.

RA是记录每个节点Election消息接收状态的，数组中每个元素对应Election消息访问到的节点号，元素值对应节点状态和节点的平均流请求量 $l({v_i})$. 定义3种接收状态：UNRECEIVED、RECEIVED、TRANSFER. UNRECEIVED表示该节点从没有收到过Election消息，RECEIVED表示该节点已经接收过Election消息且邻居节点中不存在从未接收过Election消息的节点，TRANSFER表示该节点已经接收过Election消息且邻居节点中存在从未接收过Election消息的节点.

Election消息基于RA中的节点状态进行传递，图2给出Election消息流程图，具体流程描述如下.

1）满足Election消息发送条件，根据该节点状态信息初始化Election消息.

2）发送Election消息到NW值最大的邻居节点.

3）若该节点NW值大于Election消息中的控制节点NW值，则更新Election消息；否则，Election消息RA元素个数加1.

4）若RA分组中每个元素的平均流请求量 $l({v_i})$ 之和超过控制节点容量，则转到8）；否则，根据 Election消息中RA分组的各节点接收状态，判定邻居节点的接收状态.

5）若存在相邻的UNRECEIVED节点，则将该节点接收状态标记为TRANSFER，并将Election消息转发到该节点上. 若有多于一个的UNRECEIVED节点，则选择具有较大NW值的节点进行转发；否则，转到6）.

6）若相邻TRANSFER节点不等于1，则将本节点访问状态标记为RECEIVED，并将Election消息转发到该节点上. 若存在多个TRANSFER节点，则选择具有较大NW值的节点进行转发；否则，转到8）.

7）邻居节点在接收到Election消息后，返回3）进行比较.

8）将该节点状态标记为RECEIVED，选举结束.

如图3所示为DCNE的计算过程. 图中，数字既表示节点ID，也表示节点权重NW. 从图3（a）可以看出，在网络控制节点7故障后，故障域内失控节点形成分布式的网络拓扑，如图3（b）所示. 假设节点4首先检测到控制节点故障并满足Election消息发送条件. 基于分布式的网络控制方式，每个节点能够获取邻居节点状态信息，计算得到自身NW值. 随着节点状态的改变和Election消息的传递，选举消息最终停留在节点1.

在Election消息结束传递后，会停留在某一节点. 此时，节点发送Controller消息进行控制节点的通知. Controller消息中除包含控制节点的ID号和NW值外，还包含接收数组RA. 为了避免Controller消息的重复发送，节点会在数组RA中将要发送的节点状态设置为RECEIVED.

如图4（a）所示，节点1进行Controller消息的通知，发送该消息前，会将接收数组RA中节点2和6的状态设置为RECEIVED，目的是防止Controller消息到达节点2时仍然认为节点6是与它相邻的没有被访问过的节点，向节点6发送Controller消息. 通过在发送Controller消息前对接收数组RA中节点状态进行提前的设置，可以有效地解决该问题. 图4（b）给出选举进程结束后集中式网络控制模式下的网络示意图.

1）新节点的加入. 在机载网络环境下，由于节点的移动性和链路的中断，可能在Election消息传递过程中，继续有新的失控节点加入到控制器的选举中. 新节点的加入不仅影响到节点NW值，而且影响到Election消息在网络中进行传递. 为了避免新节点的加入干扰正常的选举进程，本文算法规定节点收到Election消息后，将不会因为新节点的加入而更改节点NW值和节点状态，直到选举结束后，再根据控制节点容量情况决定新节点是否可以加入到控制域中.

2）失控节点间的拆分与合并. 在一些极端情况下，控制器的故障可能直接导致控制域内节点间的不连通，造成失控节点间的拆分，成为多个失控节点组. 当失控节点组规模满足Election消息发送条件时，节点组会分别选举出对应的控制节点. 在该情况下，随着节点的移动或链路的恢复，当2个节点组连通时，失控节点组会进行合并. 为了避免控制节点过多影响控制平面性能，若合并后的失控节点总业务量不超过具有最大NW值的控制节点容量，则选取最大NW值的节点作为整个失控节点组的控制节点. 失控节点组拆分与合并场景下的控制器选举示意图如图5所示.

由于目前将SDN技术思想应用于机载网络环境还处于理论分析阶段，尚不存在面向机载网络的SDN/IP的混合网络传输方法和实际应用的具体数据作为参考. 为了验证DCNE算法在机载网络环境下的适用性和有效性，基于MATLAB仿真软件搭建基本的控制器故障场景，从故障恢复后的控制域性能角度，对比分析不同算法的计算结果. 在场景参数设置方面，在不影响算法验证正确性的基础上，为了简化实验，假设每个节点的平均流请求量为0~2 packet/ms的随机值，节点所搭载控制器能够处理的最大容量为20~30 packet/ms的随机值. 表1给出仿真场景的相关参数设置. 在实际工程应用时，可以添加负载统计模块，对节点发出的PACKET_IN进行周期性统计，形成节点的平均流请求量.

考虑到目前还没有类似的分布式算法被用于SDN的控制器故障恢复问题. 为了验证DCNE算法的有效性，采用控制路径的最大时延指标和流策略部署开销指标这2种性能尺度，对选举结果进行评判，并与文献[17]的控制器弹性恢复机制（resilient SDN controller scheme，ReON）对比，验证DCNE算法的有效性. 参考控制器部署问题^[18]（controller placement problem，CPP）中的求解思路，通过穷举算法（brute force，BF）进行遍历搜索的方式，计算故障域内最优的控制器部署位置作为参考. 对比的故障恢复算法描述如表2所示. 其中，最大时延指标 ${T_{\max }}$ 为单个控制域内传输节点与控制节点之间平均传输时延与最大传输时延之和，反映控制域内传输时延的整体情况. ${T_{\max }}$ 越小，控制消息的到达时间和到达时差越小，网络进行控制的效率越高. 流部署开销指标 ${O_{\rm avg}}$ 包括传输节点向控制器的平均PACKET_IN请求数量和交换机到控制器间的传递开销. ${O_{\rm avg}}$ 越小，控制节点响应网络事件并完成流策略部署的代价越少. 这2种性能尺度的计算公式如下：

(6) ${T_{\max }} = \max \mathop {\min }\limits_{v \in V} d(v,c) + \frac{1}{N}\sum\limits_{v \in V} {\min }\; d(v,c),$

(7) ${O_{\rm avg}} = \frac{1}{N}\sum\limits_{v \in V} {(l(v)} f(v,c)).$

式中：c表示故障恢复后的控制节点，V为该控制域内的传输节点集合，N为传输节点总数， $d(v,c)$ 为传输节点与控制节点的最短路径时延集合， $f(v,c)$ 为传输节点与控制节点的路由跳数.

为了模拟单个控制域的网络传输情况，验证不同网络状况下选举算法的有效性. 在场景范围内，随机生成节点数量为18的初始节点布局，其中包括1个控制节点数量（根据文献[12]算法确定初始位置）和2个邻域的传输节点（位置随机）. 从初始布局开始（即时间轴上的0时刻），每隔20 s计算此时的最大时延指标及流部署开销指标，作为故障前的性能对比. 假设该时刻下控制节点发生故障，计算不同算法的控制节点恢复结果，记录不同算法的网络性能，实验总共持续120 s.

图6、7分别给出不同网络状况及故障时刻下最大时延指数和流部署开销指数的变化趋势. 图中，虚线表示故障前的性能指标. 可以看出，随着节点的移动，初始状况下最优的控制节点位置逐渐因为网络拓扑结构和节点流量的变化，性能逐渐下降. 最大时延指标最高增长约33%，流部署开销指标最大增长约75%. 这表明在机载网络环境下，根据网络环境的变化进行控制节点位置的切换，能够有效地提升网络性能. 利用3种算法均能够实现控制节点位置的重新计算，其中CPP算法最优，最大提升约25%.

从图6、7中控制器故障恢复后的部署结果（实线表示）可以看出，本文的DCNE算法明显优于ReON算法，更接近最优的BF算法. BF求解算法是从网络全局角度对控制器部署进行集中式计算，难以直接应用到控制器故障恢复场景. ReON算法虽然通过确定备份控制器可以解决控制器故障问题，但是由于节点的高移动性和故障时间的不确定性，备选控制节点因为节点移动和网络状况的变化而性能下降. 这2类算法与本文分布式的选举算法在计算方式上有本质区别，仅从故障恢复后控制节点位置性能的角度，对不同算法的计算结果进行评判.

图8、9给出不同节点数量W下最大时延指标和流部署开销指标的变化趋势. 考虑到新节点加入和控制节点处理能力限制对故障恢复性能的影响，在实验中，失控节点数量分别为15、25和35. 每种节点数量下，网络总的流请求数量不变. 考虑到相邻控制域的传输节点可能因为节点移动或者链路中断成为失控节点，参与到故障控制域内的控制器的选举中，因此设置故障恢复后的控制域最大可管理节点数量分别为10、20和30. 为了排除节点初始分布位置不同对算法验证的影响，实验中每种节点数量下的计算结果是通过以下方式获得：在场景区域内随机生成20个不同的拓扑结构（网络拓扑均为连通的）分别进行实验，取每个拓扑结构下的算法计算结果的均值作为最终结果.

从图8、9可以看出，当节点数量超过20时，利用本文算法得到的最大时延指标和流部署开销指标均优于BF和ReON算法. 这是由于BF和ReON算法在计算过程中仅考虑原控制域内节点，没有考虑到控制器故障后域内部分节点的迁移和新失控节点的加入. 本文的选举算法在Election消息的传递和计算过程中，综合考虑了节点邻居密度和本地区域的流配置需求，导致Election消息偏向于节点密度高和流部署需求高的位置传递，因此性能更优. 结合该实验可以看出，与集中式基于全局考虑控制器故障恢复的方案相比，采用分布式的方式通过合理的参数以及选举流程的设计DCNE算法，能够保证故障恢复后的控制器位置性能，适用于机载网络环境.

本文针对机载网络环境下的控制器故障恢复问题，提出分布式的控制节点选举算法. 与现有的控制器故障解决方案相比，DCNE算法将控制器的恢复问题交由本地节点间协商解决，基于本地节点获取的局部有限的邻居节点信息，合理计算选举权值，能够有效保证控制器故障恢复后的网络性能，增强了控制平面的健壮性，适用于航空集群的网络环境. 本文首次将分布式的领导人选举算法应用到机载网络环境下的控制器故障恢复问题中，是一种新的尝试，为解决相似网络场景下的该类问题提供了新思路.