一种光网络业务故障恢复的方法和系统

摘要

本发明涉及光通信领域，特别是涉及一种光网络业务故障恢复的方法和系统。方法包括：集中控制器根据网络中所有分布式控平节点上报的全网拓扑信息和业务连接信息，同步建立全网拓扑信息库和全网业务连接信息库；接收网络故障链路信息上报，根据故障业务类型确定重路由的计算类型；集中控制器生成每个故障业务对应的重路由连接路径计算任务，集中控制器根据重路由的计算类型将计算任务分配至集中控制器或分布式控平节点进行处理，集中控制器根据计算结果向控平节点发送重路由路径；根据重路由后的连接状态更新全网拓扑信息库和全网业务连接信息库。提高了重连路径计算效率，消除了路径资源分配冲突，提供了高效可靠的光网络故障业务恢复的方法。

权利要求

1.一种光网络业务故障恢复的方法，其特征在于，包括：集中控制器根据网络中所有分布式控平节点上报的全网拓扑信息和业务连接信息，同步建立全网拓扑信息库和全网业务连接信息库；

接收网络故障链路信息上报，根据故障业务类型确定重路由的计算类型，根据重路由的计算类型，分配集中控制器或分布式控平节点对重路由的连接路径进行计算，为集中控制器建立第一类连接队列，将需要集中控制器计算的重路由连接放入第一类连接队列，为每个分布式控平建立一个第二类连接队列，将需要分布式控平节点计算的重路由连接放入各自对应的第二类连接队列，其中，第一类连接队列和第二类连接队列中的重路由连接根据故障业务上报顺序和/或故障业务的优先级排序；

集中控制器生成每个故障业务对应的重路由连接路径计算任务，集中控制器根据重路由的计算类型将第一类连接队列中的计算任务依次分配至集中控制器进行处理，将第二类连接队列中的计算任务依次分配至分布式控平节点进行处理，集中控制器根据计算结果向控平节点发送重路由路径；

根据重路由后的连接状态更新全网拓扑信息库和全网业务连接信息库。

2.根据权利要求1所述的光网络业务故障恢复的方法，其特征在于，所述重路由的计算类型，具体包括：

集中控制器基于全网拓扑信息库和全网业务连接信息库计算重路由的连接路径；

和/或，集中控制器向故障节点所在的控制平面发送计算请求，由控制平面中的分布式控平节点基于全网拓扑信息库对重路由进行分布式计算，并将重路由结果上报至集中控制器进行校验。

3.根据权利要求1所述的光网络业务故障恢复的方法，其特征在于，所述根据计算结果进行重路由，具体包括：

向故障节点所在的控制平面下发重路由的连接路径，分布式控平节点使用ASON信令控制相应节点建立重路由连接，对故障前的业务进行业务恢复。

4.根据权利要求1所述的光网络业务故障恢复的方法，其特征在于，所述集中控制器根据重路由的计算类型将计算任务分配至集中控制器或分布式控平节点进行处理，还包括：当集中控制器无计算任务时，将分布式控平节点待算任务中连接路径中最深的任务分配至集中控制器进行计算。

5.根据权利要求2所述的光网络业务故障恢复的方法，其特征在于，所述将重路由结果上报至集中控制器进行校验，具体包括：集中控制器对分布式控平节点返回的重路由连接路径进行校验，判断重路由连接路径是否可用；

若重路由连接路径不可用，增加约束条件后，再次由分布式控平节点对重路由的连接路径进行计算；

若重路由连接路径可用，重路由连接路径校验通过，根据计算结果对故障业务进行重路由。

6.根据权利要求5所述的光网络业务故障恢复的方法，其特征在于，所述增加约束条件，具体包括：

集中控制器解析重路由连接路径，获取校验失败的原因；

根据校验失败的原因生成重路由的约束条件，在需计算的路径信息中增加重路由的约束条件，将约束条件发回至分布式控平节点。

7.根据权利要求1所述的光网络业务故障恢复的方法，其特征在于，所述同步建立全网拓扑信息库和全网业务连接信息库之前，还包括：建立PCEP服务端接口，使用集中控制器作为PCE服务端，通过PCEP服务端接口与每个分布式控平节点建立PCEP会话连接。

8.根据权利要求1所述的光网络业务故障恢复的方法，其特征在于，所述同步建立全网拓扑信息库和全网业务连接信息库，具体包括：集中控制器接收链路或每个分布式控平节点上报的链路拓扑信息，存入全网拓扑信息库；

集中控制器接收链路或每个分布式控平节点上报的本地业务连接信息，存入全网业务连接信息库。

9.根据权利要求1所述的光网络业务故障恢复的方法，其特征在于，所述接收网络故障链路信息上报，具体包括：

分布式控平节点接收链路的告警消息，生成链路故障消息，上报至集中控制器。

10.一种光网络业务故障恢复的系统，其特征在于，包括：集中控制器子系统和至少一个分布式控平节点子系统，所述集中控制器子系统和每个分布式控平节点子系统之间通过PCEP接口进行消息交互，完成如权利要求1‑9任一项中相应的光网络业务故障恢复的方法。

说明书

一种光网络业务故障恢复的方法和系统

【技术领域】

[0001] 本发明涉及光通信领域，特别是涉及一种光网络业务故障恢复的方法和系统。【背景技术】

[0002] 光通信网络的应用中，为了保证通信的稳定，当网络链路或网络节点故障时，经过故障点的多条业务需要尽快恢复连接，以减少业务流量损失。

[0003] 目前的光网络智能系统的故障恢复通常使用两种控制技术：第一种是基于自动交换光网络(Automatic Switching Optical Network，简写为：ASON)的分布式控制平面技
术，由不同故障业务所在的控制平面分别并行计算重路由连接路径，能够实现部分故障业
务快速恢复，但是，由于不同故障业务源节点控平基于本地拓扑信息库并行计算路径、分配
网络资源，可能产生不同分布式控平节点计算获得的重路由网络资源相互冲突，导致部分
重路由连接建立失败。第二种是基于软件定义网络(Software Defined Network，简写为：
SDN)的集中式控制器技术，SDN的控制核心采用集中式路径计算单元(Path Computation 
Element，简写为PCE)技术，基于全网拓扑和业务连接信息，全局优化计算多条故障业务连
接路径，但是，所有控平中的的故障业务都需要由集中控制器进行计算，集中控制器的计算
压力较大，并且，为消除资源冲突，需要按顺序计算多条重路由连接路径，对于顺序靠后的
故障业务会产生较大的算路延时，影响故障业务恢复实时性要求。

[0004] 鉴于此，如何克服现有技术所存在的缺陷，解决目前两种故障恢复技术各自的缺陷，是本技术领域待解决的问题。
【发明内容】

[0005] 针对现有技术的以上缺陷或改进需求，本发明解决了目前单独使用分布式控制平面技术或单独使用集中是控制器技术时计算结果的可用性和计算效率矛盾的问题。

[0006] 本发明实施例采用如下技术方案：

[0007] 第一方面，本发明提供了一种光网络业务故障恢复的方法，具体为：集中控制器根据网络中所有分布式控平节点上报的全网拓扑信息和业务连接信息，同步建立全网拓扑信
息库和全网业务连接信息库；接收网络故障链路信息上报，根据故障业务类型确定重路由
的计算类型；集中控制器生成每个故障业务对应的重路由连接路径计算任务，集中控制器
根据重路由的计算类型将计算任务分配至集中控制器或分布式控平节点进行处理，集中控
制器根据计算结果向控平节点发送重路由路径；根据重路由后的连接状态更新全网拓扑信
息库和全网业务连接信息库。

[0008] 优选的，重路由的计算类型，具体包括：

[0009] 集中控制器基于全网拓扑信息库和全网业务连接信息库计算重路由的连接路径；和/或，集中控制器向故障节点所在的控制平面发送计算请求，由控制平面中的分布式控平
节点基于全网拓扑信息库对重路由进行分布式计算，并将重路由结果上报至集中控制器进
行校验。

[0010] 优选的，根据计算结果进行重路由，具体包括：向故障节点所在的控制平面下发重路由的连接路径，分布式控平节点使用ASON信令控制相应节点建立重路由连接，对故障前
的业务进行业务恢复。

[0011] 优选的，集中控制器根据重路由的计算类型将计算任务分配至集中控制器或分布式控平节点进行处理，还包括：当集中控制器无计算任务时，将分布式控平节点待算任务中
连接路径中最深的任务分配至集中控制器进行计算。

[0012] 优选的，将重路由结果上报至集中控制器进行校验，具体包括：集中控制器对分布式控平节点返回的重路由连接路径进行校验，判断重路由连接路径是否可用；若重路由连
接路径不可用，增加约束条件后，再次由分布式控平节点对重路由的连接路径进行计算；若
重路由连接路径可用，重路由连接路径校验通过，根据计算结果对故障业务进行重路由。

[0013] 优选的，增加约束条件，具体包括：集中控制器解析重路由连接路径，获取校验失败的原因；根据校验失败的原因生成重路由的约束条件，在需计算的路径信息中增加重路
由的约束条件，将约束条件发回至分布式控平节点。

[0014] 优选的，同步建立全网拓扑信息库和全网业务连接信息库之前，还包括：建立PCEP服务端接口，使用集中控制器作为PCE服务端，通过PCEP服务端接口与每个分布式控平节点
建立PCEP会话连接。

[0015] 优选的，同步建立全网拓扑信息库和全网业务连接信息库，具体包括：集中控制器接收链路或每个分布式控平节点上报的链路拓扑信息，存入全网拓扑信息库；集中控制器
接收链路或每个分布式控平节点上报的本地业务连接信息，存入全网业务连接信息库。

[0016] 优选的，接收网络故障链路信息上报，具体包括：分布式控平节点接收链路的告警消息，生成链路故障消息，上报至集中控制器。

[0017] 另一方面，本发明提供了一种光网络业务故障恢复的系统，包括集中控制器子系统和至少一个分布式控平节点子系统，所述集中控制器子系统和每个分布式控平节点子系
统之间通过PCEP接口进行消息交互，完成如第一方面中相应的光网络业务故障恢复的功
能。

[0018] 与现有技术相比，本发明实施例的有益效果在于：通过将分布式控制平面技术和集中式控制器技术相结合，由集中控制器对网络连接数据和业务数据进行整合，并对计算
资源进行统一调配管理，并调度分布式控平节点进行并行计算，充分利用了网络计算资源，
提高了故障业务重连路径计算效率。并且，在优选方案中，通过集中控制器对分布式控平节
点的计算结果进行校验，保证了重路由的路径可用，消除了分布式计算路径资源分配冲突，
提供了一种高效可靠的光网络故障业务恢复的方法。
【附图说明】

[0019] 为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于
本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他
的附图。

[0020] 图1为本发明实施例提供的一种光网络业务故障恢复的方法流程图；

[0021] 图2为本发明实施例提供的另一种光网络业务故障恢复的方法流程图；

[0022] 图3为本发明实施例提供的一种光网络业务故障恢复的方法使用的任务队列示意图；

[0023] 图4为本发明实施例提供的另一种光网络业务故障恢复的方法使用的任务队列示意图；

[0024] 图5为本发明实施例提供的一种光网络业务故障恢复的方法使用的网络拓扑结构示意图；

[0025] 图6为本发明实施例提供的另一种光网络业务故障恢复的方法使用的网络拓扑结构示意图；

[0026] 图7为本发明实施例提供的一种光网络业务故障恢复的系统架构示意图；

[0027] 其中，附图标记如下：

[0028] 1：集中控制器子系统，11：全网业务连接管理模块，12：全网拓扑信息库，13：全局优化路径计算模块，14：重路由连接算路分类管理模块，15：网络业务连接控制模块，

[0029] 2：分布式控平节点子系统，21：本地业务连接管理模块，22：网络拓扑管理模块，23：本地路径计算模块，24：本地业务连接控制模块，25：本地资源管理模块，26：信令模块。
【具体实施方式】

[0030] 为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不
用于限定本发明。

[0031] 本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。

[0032] 此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。

[0033] 实施例1：

[0034] 在光通信过程中，为了减少网络链路或网络节点故障对业务的影响，光网络智能控制系统支持业务的端到端路径自动建立和故障连接重路由自动恢复。按照传送网拓扑自
动发现协议ITU‑T G.7714.1，光网络控制系统能够自动发现链路，并建立基于流量工程
(Traffic Engineer，简写为：TE)的全网拓扑信息库(Traffic Engineer Database，简写为
TED)。当控制系统接收到端到端业务的连接建立请求，或接收到故障告警触发业务连接端
到端重路由恢复时，控制系统将会基于全网拓扑信息库计算端到端连接路径，分配传送资
源，向传送网元节点下发业务连接配置，实现光网络业务端到端连接自动建立或重路由恢
复。

[0035] 光网络智能系统的故障自动恢复常用的两种控制技术：

[0036] 第一种基于ASON的分布式控制平面(以下简称为控平)技术，ASON控平核心由链路管理协议(Link Manager Protocol，简写为：LMP)、基于流量工程扩展的资源预留协议
(Resource ReSerVation Protocol‑Traffic Engineering，简写为：RSVP‑TE)、带流量工程
的开放式最短路径优先协议(Open Shortest Path First‑Traffic Engineering，简写为：
OSPF‑TE)和端到端路径计算技术组成，在网络各设备节点上独立运行ASON控平系统，控平
节点通过LMP协议发现本节点TE链路，通过OSPF‑TE协议相互洪泛通告TE链路，分布式构建
全网TE拓扑信息库，业务源节点控平基于全网拓扑，通过路径算法计算端到端业务标签交
换连接(Label Switch Path，简写为：LSP)，通过RSVP‑TE协议，沿着LSP路径端到端发放业
务连接，逐节点下发业务设备配置。当故障发生时，由故障业务的源节点所在的控平节点分
布式并行计算本控平内故障业务的重路由连接路径，再由路径节点并行配置重路由连接，
通过并行计算实现故障业务的快速恢复。但是，由于不同故障业务源节点所在的控平仅基
于本地拓扑信息库并行计算路径、分配网络资源，不同控平节点计算的重路由连接可能分
配了相同的网络资源产生冲突，导致部分重路由连接建立失败，尽管控平的重试机制会触
发失败连接重算，但是降低了故障业务重路由恢复性能，增加了控平节点计算负荷，并且控
平没有全网连接信息，基于全网拓扑信息库算路不能实现全局优化路径计算，降低了故障
业务重路由恢复成功率。

[0037] 第二种基于SDN的集中式控制器技术，SDN控制核心采用集中式路径计算单元(Path Computation Element，简写为：PCE)技术,部署控制服务器与各网元设备节点连接，
设备节点自动发现链路并上报集中控制器，集中控制器构建全网TE拓扑信息库和业务连接
信息库，通过集中式全局优化路径算法计算端到端业务标签交换连接，集中控制器将路径
计算结果直接下发至链路，并配置设备网元节点，集中控制业务连接创建和重路由恢复。由
于集中控制器基于全网拓扑和业务连接信息进行路径重算，因此可以支持全局优化计算多
条故障业务连接路径，没有资源分配冲突问题，能够保证故障业务恢复成功率。但是，集中
控制器需要计算全网所有的故障业务恢复路径，在故障数量较多时，集中控制器计算压力
较大。另一方面，为了消除不同路径之间的资源冲突，需要按照顺序对每个故障业务的重路
由连接路径进行计算，对于队列尾部的故障业务会产生较大的算路延时，影响故障业务恢
复实时性要求。

[0038] 综合上述两种控制技术优缺点，现有技术中提出了一种集中和分布式控制技术相结合的改进型控制方法。当网络故障时，集中控制器优先控制故障业务恢复，全局优化计算
重路由连接路径，下发设备重路由连接配置；当需要同时恢复的故障业务重路由连接较多、
集中控制器处理压力较大、故障恢复业务时延较长时，集中控制器将部分故障业务重路由
连接委托给业务源节点控平，由控平节点分布式计算重路由连接路径，实现故障业务重路
由恢复。但是，现有技术中分布式控平节点中没有全网业务连接信息，不支持全局优化路径
计算，并且不同控平节点并行计算的重路由连接路径可能存在网络传送资源分配冲突，会
导致重路由连接路径重算或计算失败，使故障业务快速恢复性能和成功率降低。

[0039] 为了解决上述问题，本发明提供的业务故障恢复方法中，由集中控制器对全网拓扑信息和全网业务连接信息进行同步统一管理，对计算资源进行统一分配。并且，在分布式
控平节点对重路由的连接路径进行计算后，不直接进行重路由，而是上报至集中控制器根
据全网业务连接信息进行校验后再执行重路由，避免了现有技术中分布式控平节点的计算
结果只能根据链路的重路由结果确认计算结果是否正确的问题，节省了路径下发、重路由
尝试和重路由结果上报的时间和资源，提高了业务故障恢复的效率和路径选择的准确性。

[0040] 如图1所示，本发明实施例提供的光网络业务故障恢复的方法具体步骤如下：

[0041] 步骤101：集中控制器根据网络中所有分布式控平节点上报的全网拓扑信息和业务连接信息，同步建立全网拓扑信息库和全网业务连接信息库。

[0042] 进行业务故障恢复时，为了找到绕过故障节点连接故障业务两端的路径，需要知道网络中所有可用链路节点连接的拓扑信息，以及需要重路由的业务的连接信息。在每个
控平内，根据LMP协议，分布式控平节点会接收链路上报的网络连接拓扑信息，并分布式保
存为本控平的拓扑信息库。在一般的分布式控平技术应用中，各分布式控平节点通过互相
通报获取其它控平的网络拓扑信息，会造成通信资源占用和时间占用。在本实施例中，由集
中控制器接收每个分布式控平节点上报的链路拓扑信息，存入全网拓扑信息库，同时，每个
分布式控平节点上会同步保存一份全网拓扑信息库；由集中控制器接收每个分布式控平节
点上报的本地业务连接信息，存入全网业务连接信息库。集中控制器通过同步全网拓扑信
息和全网业务信息，构建全网拓扑信息库和全网业务信息库，拥有了全局的拓扑连接信息
和业务信息，从而能够对全网的业务连接进行集中协调控制，避免产生业务连接冲突。集中
控制器仅需访问全网拓扑信息库和全网业务连接信息库即可获取到全网的拓扑信息和全
网的业务连接信息，数据获取更完整、获取效率更高。同时，各分布式控平节点也可以使用
全网拓扑信息库进行路径连接计算，避免使用通报方式分别获取其他控平拓扑信息造成的
效率降低。进一步的，由于网络资源和网络节点的连接状态随时可能因重路由或故障等原
因产生变动，因此每个控平内的拓扑信息库和业务连接信息库需要随时根据链路上报进行
实时更新，集中控制器保存的全网拓扑信息库和全网业务连接信息库也需要根据每个分布
式控平节点上报的信息进行同步更新，以保证路径重算时使用的拓扑信息和业务连接信息
都与当前的实际连接情况一致。

[0043] 步骤102：接收网络故障链路信息上报，根据故障业务类型确定重路由的计算类型。

[0044] 现有的控制方案中，仅由每个分布式控平节点分别处理本控平内的故障信息，或仅由集中控制器直接处理每个链路提交的故障信息。在本实施例中，每个控平接收本控平
内所有链路的告警信息，生成拓扑链路故障消息，上报至本控平的分布式控平节点，分布式
控平节点接收链路的告警消息，生成链路故障消息，上报至集中控制器。集中控制器根据控
平上报的故障消息更新全网拓扑信息库和全网业务连接信息库，并遍历每个故障链路上全
部业务连接，创建每条故障业务的待重路由连接。

[0045] 具体实施过程中，可以根据业务连接是否存在非同源的连接等业务类型区别确定合适的计算类型。在本实施例中，对于每个单独的故障业务，计算类型包括：使用集中控制
器完成路径重算和重路由，以及使用分布式控平节点对故障业务完成路径重算和重路由。
对于全部故障业务，集中控制器和每个分布式控平节点并行完成计算任务，在同一时间点
可能仅有一个计算设备进行计算，也可能由多个计算设备同时进行计算。

[0046] 步骤103：集中控制器生成每个故障业务对应的重路由连接路径计算任务，集中控制器根据重路由的计算类型将计算任务分配至集中控制器或分布式控平节点进行处理，集
中控制器根据计算结果向控平节点发送重路由路径。

[0047] 为了避免现有技术中单独使用集中控制器或单独使用分布式控平节点所产生的问题，将需要恢复的业务按照业务类型匹配合适的计算类型，再根据计算类型选择合适的
计算节点进行路径重算和重路由，本发明实施例中，计算节点为进行路径连接计算的集中
控制器和分布式控平节点。

[0048] 对于不同的故障业务，集中控制器根据计算类型将计算任务分配至不同的计算设备。以下简单提供一些具体实施场景中计算任务分配的实例，也可以根据实际情况按照计
算类型进行不同的分配。

[0049] (1)将非同源的需要进行全局优化计算的业务分配至集中控制器，由集中控制器基于全网拓扑信息库和全网业务连接信息库计算重路由的连接路径，获得全局范围内最优
化的无冲突路径。

[0050] (2)将路径仅限于一个控平内的业务分配至所在控平的分布式控平节点，向故障节点所在的控制平面发送计算请求，由控制平面中的分布式控平节点对重路由进行分布式
计算，并将重路由结果进行上报，在不产生冲突的前提下，通过分布式计算减少集中控制器
的计算负担，提高业务故障恢复效率。

[0051] (3)先由分布式控平节点计算与本控平相关的业务，再由集中控制器对每个控平的路径计算结果进行冲突校验，并将校验失败的路径发回分布式控平节点重新计算，在通
过分布式计算提高计算效率的情况下，避免了因并行计算或链路资源变化而产生的路径冲
突或资源冲突。

[0052] 在多任务的情况下，同时使用集中控制器和多个分布式控平节点进行并行计算，提高故障业务的处理效率，减少了故障恢复的等待时间。

[0053] 为了进一步提高计算效率，充分利用计算资源，当集中控制器无计算任务时，可以将分布式控平节点中的一些待算的连接路径分配至集中控制器进行计算。由于越深的连接
路径涉及到的连接数量越多，越可能与其它路径产生冲突，在本实施例的优选方案中，将分
布式控平节点待算任务中连接路径中最深的任务分配至集中控制器进行计算。

[0054] 对重路由的连接路径进行计算后，集中控制器向分布式控平节点进行重路由连接发布，通过信令消息，沿连接路径逐节点下发重路由的设备连接配置，完成重路由连接建
立，实现业务连接的恢复，确保业务两端正常通信。

[0055] 步骤104：根据重路由后的连接状态更新全网拓扑信息库和全网业务连接信息库。

[0056] 根据连接路径计算结果进行重路由后，网络链路根据重路由的路径重新建立了链接，网络节点之间的链路连接关系发生了变化，业务两端的连接路径也发生了变化。为了保
证每次重路由后用于业务恢复的拓扑信息和业务连接信息与当前网络的实际连接情况一
致，还需要由链路或分布式控平节点上报重路由连接建立的结果，对全网拓扑信息库和全
网业务连接信息库进行更新和同步，以保证后续计算种使用最新的拓扑信息和业务连接信
息。

[0057] 通过步骤101‑步骤104，同时使用集中控制器和分布式控平节点作为路径重算和重路由的控制器，结合了分布式控制平面技术和集中式控制器技术的优势，既能够减少路
径冲突，又能够提高路径计算的效率。

[0058] 在本发明实施例的具体实施场景中，也可以使用任一种能够实现本发明提供的方法的链路协议和网络传输协议。在优选方案中，网络链路为TE链路，全网拓扑信息库为全网
TE拓扑信息库；集中控制器为SDOTN集中控制器；分布式控平节点为ASON控平节点；集中控
制器作为PCE服务端与分布式控平节点进行会话；分布式控平节点通过南向接口，如PCEP或
OSPF‑TE协议等接口，向集中控制器上报链路信息、业务信息、故障信息和重路由的路径计
算结果等数据；集中控制器通过PCEP协议向分布式控平节点下发路径连接计算任务、校验
结果、全网拓扑信息库或全网业务连接信息库等数据。常规的ASON技术中，各控平节点在自
动触发故障重路由时独立完成计算，在涉及到全网拓扑数据同步以及E2E计算的场景中，会
产生管理规模的问题。因此，需要使用PCE协议来解决分布式ASON控平节点的单机性能有
限、管理规模无法快速增长的问题。在实际使用中，若单个PCE服务端的自身计算能力不足，
还可以进行多级PCE的级联，进一步扩大网络管理规模。

[0059] 进一步的，在使用PCEP接口的实施场景中，为了在集中控制器和分布式控平节点之间正确建立PCEP会话连接，需要首先建立PCEP服务端接口，将集中控制器作为PCE服务端
与每个控平节点建立PCEP会话连接。同时，集中控制器还需要维护PCEP协议接口，确保网络
连接的稳定。

[0060] 由于分布式控平节点无法获取全网业务连接信息，同时也由于分布式并行计算或网络资源变动等原因，由不同分布式控平节点计算的多条重路由连接路径可能会出现资源
冲突。在现有的方案中，分布式控平节点无法校验识别资源冲突，直接使用分布式控平的计
算结果可能导致重路由失败，产生时间和资源的浪费。本发明实施例中，分布式控平节点对
重路由连接路径进行计算后，不直接使用计算结果进行重路由，而是将计算结果上报至集
中控制器，由集中控制器对不同分布式控平节点返回的重路由连接路径进行校验，判断重
路由连接路径是否可用。若重路由连接路径不可用，增加约束条件后，再次由分布式控平节
点对重路由的连接路径进行计算；若重路由连接路径可用，重路由连接路径校验通过，根据
计算结果对故障业务进行重路由。本实施例提供的方法中，集中控制器统一管理全网的拓
扑信息库和全网业务连接信息库，因此可以根据全网信息对分布式控平节点计算得到的连
接路径进行校验和统一管理，并在校验失败后直接执行重算步骤，避免了分布式控平节点
直接进行重路由可能导致的重路由失败和资源冲突，提高了业务故障恢复的效率。

[0061] 进一步的，为了避免重算后的连接路径再次使用前次计算失败时的冲突资源，导致重算后的路径依然不可用，还需要集中控制器解析重路由连接路径，获取校验失败的原
因，并根据校验失败的原因生成重路由的约束条件，在需计算的路径信息中增加重路由的
约束条件，再发回至原分布式控平节点进行重路由计算。如在某个路径中，由于网络节点
NE1和网络节点NE2之间的链路L12已被其它业务占用导致路径不可用，集中控制器需要将
“L12不可用”作为重路由的约束条件，发回至原分布式控平节点。

[0062] 进一步的，分布式控平节点将计算结果上报至集中控制器后，集中控制器基于全网拓扑数据库、全网业务连接信息库和其它分布式控平节点上报的路径连接，对每个分布
式控平节点上报的路径连接进行优化，查找通信效率更高、资源空闲度更高或连接更稳定
的路径连接，提高故障业务恢复之后的业务通信效率。

[0063] 具体的，如图2所示，可以通过以下步骤，结合步骤101‑步骤104，实现重路由连接路径的计算、校验和重计算。

[0064] 步骤201：接收网络故障链路上报，遍历并创建经过故障链路的全部业务重路由连接，根据故障业务类型选择重路由的计算类型。

[0065] 结合步骤102，集中控制器接收故障链路上报后，根据全网拓扑信息库和全网业务连接信息库，判断每一个业务连接是否经过故障链路，若业务连接经过故障链路，说明该业
务为故障业务，需要重新计算不经过故障链路的连接路径。接收网络故障链路上报后，还需
要对业务故障进行分类，选择合适的计算类型进行连接路径计算。

[0066] 步骤202：根据重路由的计算类型，分配集中控制器或分布式控平节点对重路由的连接路径进行计算。

[0067] 计算类型分配完成后，分别由集中控制器和分布式控平节点完成连接路径的初步计算。由于集中控制器基于全网拓扑信息库和全网业务连接信息库进行计算，因此不会产
生路径冲突导致路径不可用，只有不同的分布式控平节点计算的连接路径可能会产生冲突
导致路径不可用。但每个分布式控平节点之间无法互相进行资源整合和校验，因此需要使
用集中控制器进行校验。

[0068] 步骤203：如图3所示，为集中控制器建立第一类连接队列，将需要集中控制器计算的重路由连接放入第一类连接队列，转步骤204。为每个分布式控平建立一个第二类连接队
列，将需要分布式控平节点计算的重路由连接放入各自对应的第二类连接队列，转步骤
205。图中箭头所示方向为任务计算的顺序。

[0069] 由于业务故障恢复时采用先来先服务的调度方式，按照接收故障的时间先后和业务发生的时间先后对业务故障进行恢复，因此可以使用先进先出的队列管理需要进行重算
的路径连接，每一个队列元素表示一个故障业务连接。进一步的，为了便于管理，为每个能
独立进行路径计算的节点创建一个单独的队列。第一类连接队列存放集中控制器需处理的
故障业务连接；每一个第二类连接队列存放每一个分布式控平节点需处理的故障业务连
接，第二类连接队列中每一个元素为相同源节点的一个不同重路由连接。

[0070] 进一步的，在具体实施中，可以根据接收到故障业务上报的顺序加入队列，按照先来先服务的调度方式进行处理。也可以根据故障业务的紧急程度或重要程度划分优先级，
将较高优先级的故障业务插入队列较前的位置，再按队列顺序进行处理，以减少紧急或重
要的业务的故障恢复时间，减少紧急或重要的业务故障恢复时间较长导致的损失。

[0071] 步骤204：集中控制器按照第一类连接队列顺序分别对每一个队列元素中的故障业务进行重路由路径连接计算，并转步骤206。

[0072] 步骤205：分布式控平节点按照各自对应的第二类连接队列顺序分别对每一个队列元素中的故障业务进行重路由路径连接计算，并转步骤207。

[0073] 对业务故障分配合适的计算类型，并分别分配至不同的计算节点，使用集中控制器和多个分布式控平节点，通过协同网络资源多路径并行计算，充分利用网络中的所有计
算资源，提高系统总体的计算效率，减少业务故障恢复的总时间，避免仅使用集中控制器顺
序计算造成的等待时间过长。在进行任务分配时，使用队列对每个计算节点的计算资源进
行管理，将每个计算节点的计算任务组织为相应的连接队列，便于计算节点对任务进行获
取、分发、转分配和管理等操作。步骤204和步骤205，以及相应的后续步骤为并发执行。

[0074] 步骤206：判断第一类连接队列是否为空。若第一类连接队列为空，转步骤207；若第一类连接队列不为空，转步骤211。

[0075] 由于集中控制器中任务较少或计算效率较高等原因，集中控制器可能会处于空闲状态。为了充分利用集中控制器的计算能力，可以将分布式控平节点中的待算任务转分配
至集中控制器进行处理，以提高整体的故障恢复效率。

[0076] 步骤207：如图4所示，当第一类连接队列为空时，将第二类连接队列数组中路径深度最深的连接路径放入第一类连接队列，转步骤204由控制器进行全局优化算路。

[0077] 在第一类连接队列空闲，即集中控制器空闲时，将第二类连接队列数组中待计算的任务加入第一类连接队列中，在不等待的情况下使用空闲的计算节点协助处理分布式控
平节点中待计算的任务，减少连接路径计算任务总的等待时间。进行连接路径计算时，路径
深度越深，涉及的网络链路连接数越多，越可能会产生路径冲突，而使用集中控制器对路径
进行计算可以减少路径冲突。因此，优先选择路径深度更深的待处理任务加入第一类连接
队列，使用集中控制器进行计算，从而减少重算导致的计算效率下降，进一步提高整体的故
障业务恢复效率。

[0078] 步骤208：分布式控平节点将路径连接的计算结果上报至集中控制器，集中控制器对分布式控平节点的计算结果进行校验。

[0079] 由于分布式控平节点并行计算的特性，以及网络资源动态变化的随机性，不同的分布式控平节点所计算的连接路径可能会产生冲突。为了避免不同的分布式控平节点计算
所得的路径连接互相冲突，需要使用集中控制器将所有分布式控平节点的路径连接计算结
果进行冲突校验。

[0080] 步骤209：判断分布式控平节点上报的连接路径是否存在路径冲突。若存在路径冲突，转步骤211；不存在路径冲突，转步骤212。

[0081] 集中控制器根据全网拓扑信息库和全网业务连接信息库对所有分布式节点上报的路径连接计算结果进行校验，判断是否存在路径冲突。

[0082] 步骤210：集中控制器将校验失败的原因解析为重路由的约束条件，在需计算的路径信息中增加重路由的约束条件，转步骤205进行重算。

[0083] 路径连接校验失败后，集中控制器将存在冲突的部分进行解析，并根据冲突原因生成约束条件，如某个网络节点或网络连接已被占用等，避免重算时再次因同样的冲突原
因再次导致冲突。具体的，在集中控制器对连接路径进行校验时，获取分布式控平节点计算
的连接路径中不可用的网络资源，在下一次重算重路由连接路径时，将该不可用网络资源
作为排除条件带入算路约束加入计算任务中，再进行重算，或分配至相应的分布式控平节
点进行重算。

[0084] 步骤211：使用校验成功的路径连接的计算结果进行重路由和故障业务恢复。

[0085] 集中控制器和分布式控平节点进行故障业务恢复的路径连接计算，并校验无冲突后，即可使用计算结果进行重路由，完成故障业务恢复。

[0086] 通过步骤201‑步骤211，进一步实现了业务故障恢复中的任务管理优化、计算效率优化和计算错误处理，进一步提高了故障业务恢复的效率，降低了任务管理难度。

[0087] 经过本实施例中提供的光网络业务故障恢复的方法，控制器调度分布式控平计算资源同步完成全网重路由连接路径计算，充分利用了全网算路能力，消除多连接路径并行
计算资源冲突问题，提高网络故障恢复性能。

[0088] 实施例2：

[0089] 基于实施例1提供的光网络业务故障恢复的方法，在具体实施场景中，可以通过以下过程进行具体应用，控制多条故障业务重路由连接恢复。

[0090] 如图5所示，为本实施例使用的网络链路未发生故障时的网络拓扑图。网络拓扑图中包含NE1‑NE5五个可重构光分插复用器(Reconfigurable Optical Add‑Drop 
Multiplexer，简写为：ROADM)节点、八条链路(本实施例的链路标号中两数字分别表示链路
两端节点序号)和五条具有重路由保护恢复类型的业务LSP1‑LSP5。其中，每条业务连接名
称包含了经过路由节点编号和占用光波道，如LSP4(1‑2‑5，CH3)，表示业务连接顺序经过
NE1、NE2、NE5节点和L12、L25链路，使用第3波道。LSP4(1‑2‑5，CH3)和LSP5(3‑4，CH1)两条业
务连接相互关联，即这两条非同源业务重路由连接路径相互节点和链路分离，两条业务重
路由连接路径经过的节点和链路尽量不相同。根据步骤101，每个控平的分布式控平节点将
上述数据上报至集中控制器，集中控制器整合上述所有数据建立全网拓扑信息库和全网业
务连接信息库。

[0091] 如图6所示，链路L12发生故障，根据步骤102，集中控制器接收链路直接上报或分布式控平节点上报的上述故障信息，集中控制器收到L12链路或L12所在的分布式控平节点
的故障上报，遍历经过L12的LSP1‑LSP4四条故障业务，分别创建对应LSP1’、LSP2’、LSP3’和
LSP4’四条需进行重路由的重路由连接。

[0092] 根据步骤102，对LSP1’、LSP2’、LSP3’和LSP4’四条重路由连接依据故障业务类型选择重路由的计算类型，本实施例中根据故障业务连接是否存在关联的非同源连接选择重
路由的计算类型，并根据步骤203将分配至不同计算节点的任务保存至相应的连接队列。如
图6所示，LSP4’与非同源连接LSP5关联，将LSP4’划分为第一类重路由连接，放入第一类连
接队列，由集中控制器全局优化集中算路。LSP1’、LSP2’、LSP3’不存在关联的非同源连接，
划分为第二类重路由连接，放入对应每一个分布式控平节点的第二类连接队列数组，请求
业务源节点NE1、NE3、NE4所在控平的分布式控平节点并行计算LSP1’、LSP2’、LSP3’连接路
径。

[0093] 根据步骤103，分配集中控制器或分布式控平节点对重路由的连接路径进行计算。根据步骤204和步骤205，集中控制器和分布式控平节点分别计算分配至各自对应的连接队
列中的任务。从第一类连接队列头部取出LSP4'连接，由集中控制器进行全局优化算路。从
第二类连接队列数组头部取出LSP1’、LSP2’、LSP3’连接，分别向对应业务源节点NE1、NE3、
NE4所在控平的分布式控平节点并行发起算路请求，由对应的分布式控平节点计算LSP1’、
LSP2’、LSP3’的路径连接。

[0094] 集中控制器计算LSP4’路径LSP4’(1‑5，CH1)，L15链路分配第1波道CH1，集中控制器验证链路CH1波道可用，路径计算成功。根据步骤103，对路径连接计算成功的故障业务根
据计算结果进行重路由。向NE1控平节点下发LSP4’(1‑5，CH1)路径，LSP4’连接建立成功，
LSP4删除成功。

[0095] 根据步骤209、步骤210和步骤211，集中控制器收到NE1所在控平的分布式控平节点返回路径LSP1'(1‑5‑2，CH1)，L15、L25链路分配第1波道CH1，集中控制器检查到链路CH1
波道不可用，LSP1'(1‑5‑2，CH1)路径校验失败，将LSP1’放入第二类连接队列数组NE1节点
队列尾部进行重算。进一步的，根据步骤211，在进行路径重算之前，增加链路CH1波道不可
用作的约束条件，避免再次产生算路失败。

[0096] 使用同样的方式，对每一个分布式控平节点的计算结果完成校验，根据校验成功的路径完成重路由，将校验失败的路径发回对应的分布式控平节点进行重算。集中控制器
收到NE4控平节点返回路径LSP3'(4‑5‑1，CH1)，L45、L15链路分配第1波道CH1，集中控制器
检查到链路CH1波道不可用，LSP3'(4‑5‑1，CH1)路径校验失败，将LSP3’放入第二类连接队
列NE4节点队列尾部。集中控制器收到NE3控平节点返回路径LSP2'(3‑5‑2，CH1)，L35、L25链
路分配第1波道CH1，集中控制器校验连接路径资源可用，路径计算成功，向NE3节点控平下
发LSP2'(3‑5‑2，CH1)路径，LSP2’连接建立成功，LSP2删除成功。

[0097] 经过上述步骤，第一类连接路径中LSP4’任务计算完成，第一类连接队列为空。LSP1'和LSP3'校验失败，分别重新发回至NE1节点和NE4节点对应的第二类连接队列中。

[0098] 根据步骤207和步骤208，第一类连接队列为空时，将第二类连接队列中的任务加入第一类连接队列，由空闲的集中控制器进行处理，并在路径计算成功后进行重路由。由于
LSP1'比LSP3'的路径深度更深，集中控制器从NE1节点对应的第二类连接队列尾部取出
LSP1'连接，修改LSP1'为第一类连接，放入第一类连接队列。进一步的，为了进行并行计算
减少等待时间，集中控制器从第一类连接队列取出并全局优化计算LSP1’路径的同时，可以
并行从第二类连接队列数组头部取出LSP3’连接，向NE4节点控平发起算路请求，保持所有
计算节点都处于忙碌状态，避免因任务调度不及时导致的计算任务等待。集中控制器计算
LSP1’路径LSP1’(1‑5‑2，CH2)，L15、L25链路分配第2波道CH2，集中控制器验证路径资源可
用，路径计算成功，向NE1控平节点下发LSP1’(1‑5‑2，CH2)路径，LSP1’连接建立成功，LSP1
删除成功。集中控制器收到NE4控平节点返回路径LSP3'(4‑5‑1，CH3)，L45、L15链路分配第3
波道CH3，集中控制器验证路径资源可用，路径计算成功，向NE4控平节点下发LSP3'(4‑5‑1，
CH3)路径，LSP4’连接建立成功，LSP4删除成功，

[0099] 在上述的每一次重路由连接建立成功和故障业务连接删除完成后，网络的拓扑结构和业务连接关系都发生了变化，由图5所示的拓扑连接关系和业务连接关系，变化为图6
所示的拓扑连接关系和业务连接关系。根据步骤104，集中控制器还需要按照链路或分布式
控平节点上报的重路由后的连接状态更新全网拓扑信息库和全网业务连接信息库，以便于
后续计算时使用正确的拓扑信息和业务连接信息进行故障恢复的计算。

[0100] 在本实施例提供的网络拓扑结构和业务连接关系中，若仅使用集中式控制器技术进行故障恢复，集中控制器需要计算LSP1‑LSP4这4条重路由的路径连接，需要花费4个计算
时间单元才能完成计算，会造成LSP2‑LSP4等待时间较长，影响故障业务恢复的效率。若仅
使用分布式控制平面技术，由于LSP4’和非同源连接LSP5关联，因此可能无法使用单一的分
布式控平节点完成计算或容易产生冲突，LSP1'和LSP3'也产生了冲突需要重算，影响了故
障业务恢复的效率。若按照本实施例中的方式，采用实施例1提供的光网络业务故障恢复的
方法进行故障业务恢复，一方面通过并行计算仅使用1个计算时间单元即可完成所有路径
连接的首次计算，即使产生冲突需要重算的情况下也仅需2个计算时间单元完成所有路径
连接的计算，提高了计算效率；另一方面，将和非同源连接关联的LSP4’分配至集中控制器
进行计算，通过全局拓扑信息库和全局业务连接库的完整信息完成路径计算，避免了产生
冲突，减少了重算次数。由此可见，实施例1和本实施例提供的光网络业务故障恢复的方法
相对于两种现有的控制方法都具有优势，同时又避免了现有控制方法中的问题，合理调度
网络分布式计算资源，协同控制网络故障业务重路由恢复，提高了网络故障业务恢复性能，
满足光网络故障快速自愈智能控制需求。

[0101] 实施例3：

[0102] 在实施例1和实施例2提供的光网络业务故障恢复的方法的基础上，本实施例还提供了一种光网络业务故障恢复的系统。包括集中控制器子系统1和至少一个分布式控平节
点子系统2，集中控制器子系统1和每个分布式控平节点子系统2之间通过PCEP接口进行消
息交互。其中，集中控制器子系统1为PCEP服务端，每一个分布式控平节点子系统2为一个
PCEP客户端，共同完成如实施例1和实施例2中集中控制器和分布式控平节点相应的光网络
业务故障恢复的功能。

[0103] 如图7所示，为本实施例提供的系统结构图。

[0104] 集中控制器子系统1主要完成实施例1和实施例2中集中控制器所执行的功能，并完成相应的通信连接、信息交互和数据存储等功能。根据全网拓扑信息库和全网业务连接
信息库计算重路由连接路径，建立重路由连接，实现全网故障业务恢复。集中控制器子系统
1包括如下子模块。

[0105] 全网业务连接管理模块11，向各设备节点ASON控平子系统下发步骤103中分配至分布式控平节点的故障业务连接，同步业务连接数据，创建业务连接信息库，保存全网业务
连接信息，提供API调用接口供外部模块访问业务连接信息。

[0106] 全网拓扑信息库12，接收TE链路状态上报，根据步骤101创建TE拓扑信息库，保存全网拓扑信息，提供API调用接口功外部模块访问TE拓扑信息以便于集中控制器和分布式
控平节点进行路径连接计算，对网络业务连接控制模块通知链路故障，根据步骤104在网络
连接状态变化时进行拓扑信息更新。

[0107] 全局优化路径计算模块13，接收网络业务连接控制模块算路请求，根据步骤103基于全网拓扑信息库和全网业务连接信息对分配至集中控制器的故障业务连接路径进行计
算，返回路径计算结果。

[0108] 重路由连接算路分类管理模块14，根据步骤102将需要重路由连接的故障业务进行分类，为外部模块提供查看、修改重路由连接类型数据的API接口。

[0109] 网络业务连接控制模块15，根据步骤102接收控平链路故障通知，根据步骤103，按照计算类型将故障业务分配至全局优化路径计算模块13进行计算，或分发至分布式控平子
系统2进行协同计算。

[0110] 分布式控平子系统2主要完成实施例1和实施例2中分布式控平节点所执行的功能，并完成相应的通信连接、信息交互和数据存储等功能。根据全网拓扑信息库和全网业务
连接信息库计算所在控平内的本地重路由连接路径，建立重路由连接，实现本地故障业务
恢复。分布式控平子系统2包括如下子模块。

[0111] 本地业务连接管理模块21，管理本地节点为源节点的业务连接，接收集中控制器子系统1根据步骤103分配至本控平的分布式控平节点的业务连接，将连接配置下发至设
备，根据步骤101向集中控制器子系统1上报本地业务连接状态，提供API调用接口供外部模
块访问本地业务连接信息。

[0112] 网络拓扑管理模块22，接收本地网络资源上报，与其他各分布式控平子系统2的分布式控平节点间相互通告TE链路信息，根据步骤104同步并保存全网拓扑信息库的数据，提
供API调用接口供外部模块访问TE拓扑信息，根据步骤102向集中控制器子系统1上报故障
链路状态。

[0113] 本地路径计算模块23，接收本地业务连接控制模块21下发的算路请求，根据步骤103基于全网拓扑信息库计算故障业务的连接路径，返回路径计算结果。

[0114] 本地业务连接控制模块24，接收集中控制器子系统1分配的重路由路径连接计算请求，调度本地路径计算模块23进行路径连接计算，向集中控制器子系统1返回路径连接计
算结果。

[0115] 本地资源管理模块25，根据步骤102接收链路上报的设备故障告警，通知全网拓扑信息库更新和同步链路的资源变化。

[0116] 信令模块26，向本控平内的设备下发本控平的业务连接配置，与业务连接路径上下游节点交互ASON信令消息，按照连接路由下发本地设备配置，完成步骤103的重路由功
能。

[0117] 上述集中控制器子系统1和分布式控平节点子系统2可以使用现有的网络设备进行硬件实现，并加载与各子模块相应的功能模块以完成各子模块所需的功能。在具体实施
中，根据实际需要，各子模块可以集成在同一台硬件设备中，也可以分布在多台能够进行数
据、控制信号和信令交互的硬件设备中。

[0118] 通过本实施例提供的光网络业务故障恢复的系统，可以完成如实施例1和实施例2中提供的光网络业务故障恢复的方法，通过集中控制器子系统1集中式调度网络分布式计
算资源，协同控制各分布式控平节点子系统2并行完成网络故障业务重路由恢复，提高了网
络故障业务恢复性能，满足光网络故障快速自愈智能控制的需求。

[0119] 以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。