本发明涉及互联网领域，具体而言，涉及一种SDN架构下多业务的并行恢复方法、装置及系统。
背景技术：
随着SDN网络技术的迅猛发展，致力于制定OTN网络相关标准和架构的OIF、ONF等国际标准组织，也都将研究重点转移到了SDN上，因此，传统OTN网络向SDN架构演进已经成为大势所趋。随着网络扁平化的发展，OTN网络与PTN网络将逐步融合，越来越多的小粒度业务会接入到OTN网络中进行传输。但由于OTN网络传输带宽很高，因此，一根光缆中断将会导致几十条甚至上百条业务需要进行路由的重新恢复。
“恢复”是指通过使用网络中的空闲资源，重新选路并建立新的连接来替代出现故障的连接，其特点是无需占用过多额外的资源，只要网络中有足够的剩余资源，就能够抵抗多次故障。但由于恢复动作是一个实时感知故障并处理故障的动态过程，因此，业务受损的时间会比较长，从而使得故障处理的效率较低。基于恢复的这些特点，目前国内外各大网络运营商和设备制造商都非常关注业务的恢复性能。
针对相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，目前尚未提出有效的解决方案。
技术实现要素：
本发明实施例提供了一种SDN架构下多业务的并行恢复方法、装置及系统，以至少解决相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题。
根据本发明实施例的一个方面，提供了一种SDN架构下多业务的并行恢复方法，该方法包括：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点。
可选地，在发送配置消息至对应的OTN节点之后，方法还包括：发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
可选地，基于接收到的故障告警信息为OTN节点生成对应的配置消息包括：根据故障告警信息确定故障业务的恢复路径；确定对应于恢复路径的SNC交叉信息；生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
可选地，根据故障告警信息确定故障业务的恢复路径包括：从故障告警信息中获取故障业务的故障位置信息；根据故障位置信息生成故障业务的恢复路径。
可选地，确定对应于恢复路径的SNC交叉信息包括：获取恢复路径的路径信息；将恢复路径的路径信息转化为SNC交叉信息。
可选地，配置消息包括flow_mod消息，其中，flow_mod消息用于携带至少一个SNC交叉信息。
可选地，上述的并行恢复方法应用于SDN控制器。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复方法，该方法包括：发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，按照配置消息的指示重新配置用于执行故障业务的OTN板卡包括：基于配置消息生成一个或多个用于配置OTN板卡的配置命令；将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
可选地，在按照配置消息的指示重新配置用于执行故障业务的OTN板卡之后，该方法还包括：在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
可选地，按照预设信息的指示收集被配置的OTN板卡的配置结果包括：接收OTN板卡发送的用于表示配置失败的信息；接收OTN板卡发送的用于表示配置成功的信息；若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
可选地，基于配置消息生成一个或多个用于配置OTN板卡的配置命令包括：获取配置消息中的一个或多个SNC交叉信息；将一个或多个SNC交叉信息转换为一个或多个配置命令。
可选地，将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡包括：采用TLV格式生成对应于配置命令的TLV数据包；将用于配置同一个OTN板卡的TLV数据包携带于配置请求中，发送至对应的OTN板卡。
可选地，配置消息包括flow_mod消息，其中，flow_mod消息用于携带至少一个SNC交叉信息。
可选地，上述的并行恢复方法应用于OTN节点。
根据本发明实施例的另一个方面，提供了一种SDN架构下多业务的并行恢复装置，该装置包括：第一接收单元，用于接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；生成单元，用于基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；第一发送单元，用于发送配置消息至对应的OTN节点。
可选地，第一发送单元在发送配置消息至对应的OTN节点之后，还用于发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；装置还包括：第二接收单元，用于接收OTN节点发送的用于表示配置结果的反馈信息。
可选地，生成单元包括：第一确定模块，用于根据故障告警信息确定故障业务的恢复路径；第二确定模块，用于确定对应于恢复路径的SNC交叉信息；第一生成模块，用于生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
可选地，第一确定模块包括：第一获取子模块，用于从故障告警信息中获取故障业务的故障位置信息；生成子模块，用于根据故障位置信息生成故障业务的恢复路径。
可选地，第二确定模块包括：第二获取子模块，用于获取恢复路径的路径信息；转化子模块，用于将恢复路径的路径信息转化为SNC交叉信息。
可选地，包括：第二发送单元，用于发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；第三接收单元，用于接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；配置单元，用于按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，配置单元包括：第二生成模块，用于基于配置消息生成一个或多个用于配置OTN板卡的配置命令；发送模块，用于将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复装置，该装置包括：收集单元，用于在按照配置消息的指示重新配置用于执行故障业务的OTN板卡之后，在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；反馈单元，用于将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
可选地，收集单元包括：第一接收模块，用于接收OTN板卡发送的用于表示配置失败的信息；第二接收模块，用于接收OTN板卡发送的用于表示配置成功的信息；处理模块，用于若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
可选地，第二生成模块包括：第三获取子模块，用于获取配置消息中的一个或多个SNC交叉信息；转换子模块，用于将一个或多个SNC交叉信息转换为一个或多个配置命令。
根据本发明的另一个实施例，还提供了一种SDN架构下多业务的并行恢复系统，包括SDN控制器和OTN节点，其中，SDN控制器用于接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息，并基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；OTN节点用于接收SDN控制器发送的配置消息。
可选地，SDN控制器还用于：在发送配置消息至对应的OTN节点之后，发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明的另一个实施例，还提供了一种SDN设备，包括：SDN控制器；用于存储SDN控制器可执行指令的第一存储器；用于根据SDN控制器的控制进行信息收发通信的第一传输装置；其中，SDN控制器用于执行以下操作：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点。
可选地，SDN控制器还用于执行以下操作：在发送配置消息至对应的OTN节点之后，发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明的另一个实施例，还提供了一种OTN设备，包括：OTN控制器；用于存储OTN控制器可执行指令的第二存储器；用于根据OTN控制器的控制进行信息收发通信的第二传输装置；其中，OTN控制器用于执行以下操作：发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，OTN控制器还用于执行以下操作：基于配置消息生成一个或多个用于配置OTN板卡的配置命令；将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
根据本发明的另一个实施例，提供了一种存储介质，存储介质可以被设置为存储用于执行以下步骤的程序代码：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点，由OTN节点通过配置消息中对应于同一个OTN板卡的配置命令对同一个OTN板卡进行配置。
在本发明实施例中，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点，将某一节点的所有的配置相关信息通过一个消息包来发送，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的可选的计算机终端的示意图；
图2是根据本发明实施例的可选的业务恢复的流程图；
图3是根据本发明实施例的可选的业务恢复的流程图；
图4是根据本发明实施例的一种SDN架构下多业务的并行恢复方法的流程图；
图5是根据本发明实施例的另一种SDN架构下多业务的并行恢复方法的流程图；
图6是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图7是根据本发明实施例的可选的OXM数据结构的示意图；
图8是根据本发明实施例的可选的flow_mod消息的示意图；
图9是根据本发明实施例的可选的packet_in消息的示意图；
图10是根据本发明实施例的可选的网络拓扑结构的示意图；
图11是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图12是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图13是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图14是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图15是根据本发明实施例的一种SDN架构下多业务的并行恢复装置的示意图；
图16是根据本发明实施例的另一种SDN架构下多业务的并行恢复装置的示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
首先，在对本发明实施例进行描述的过程中出现的部分名词或术语适用于如下解释：
SDN：Software Defined Network，软件定义网络。
PTN：Packet Transport Network，分组传送网。
OTN：Optical Transport Network，光传送网。
SNC：Sub Network Connect，子网连接。
OIF：Optical Internetworking Forum，光互联网论坛。
ONF：Open Networking Foundation，开放网络基金会。
OTWG：Optical Transport Working Group，光传送工作组。
OFP：OpenFlow Protocol，OpenFlow协议。
OXM：OpenFlow Extensible Match，OpenFlow匹配扩展对象。
ODU：Oracle Database Unloader，集光纤配线单元。
实施例1
本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，如图1所示，计算机终端可以包括一个或多个(图中仅示出一个)处理器101(处理器101可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器103、以及用于通信功能的传输装置105。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。
上述的终端可以为SDN设备和OTN设备。
存储器103可用于存储应用软件的软件程序以及模块，如本发明实施例中的设备的控制方法对应的程序指令/模块，处理器101通过运行存储在存储器103内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的处理器可以为SDN设备的SDN控制器和OTN设备的OTN控制器。
上述的存储器可以为SDN设备的第一存储器和OTN设备的第二存储器。
传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。
上述的传输装置可以为SDN设备的第一传输装置和OTN设备的第二传输装置。
OpenFlow协议(OpenFlow是一种新型的网络协议，它是控制器和交换机之间的标准协议)是目前SDN架构下业界普遍认可的控制器与网络设备之间的南向协议，ONF旗下的OTWG组织也一直在对OFP进行了OTN扩展。但根据目前最新的扩展版本，一条flow_mod消息可配置单条OTN业务的单向SNC交叉,控制器、OTN网络设备代理、板卡(板卡1至板卡n)之间的交互如图2所示：
步骤S201，网络故障上报；
步骤S202，业务1的路径计算；
步骤S203，通过FLOW_MOD消息承载业务1的SNC交叉1的交叉信息；
步骤S204，发送SNC1的交叉配置命令至板卡1；
步骤S205，板卡1处理交叉配置命令；
步骤S206，发送SNC1的交叉配置命令至板卡n；
步骤S207，板卡n处理交叉配置命令；
步骤S208，发送SNC1的映射配置命令至板卡n；
步骤S209，板卡n处理映射配置命令；
步骤S210，通过FLOW_MOD消息承载业务1的SNC交叉2的交叉信息；
步骤S211，发送SNC2的交叉配置命令至板卡1；
步骤S212，板卡1处理交叉配置命令；
步骤S213，发送SNC2的交叉配置命令至板卡n；
步骤S214，板卡n处理交叉配置命令；
步骤S215，发送SNC2的映射配置命令至板卡n；
步骤S216，板卡n处理映射配置命令；
步骤S217，发送业务1的BARRIER_REQUEST消息，以要求返回处理结果；
步骤S218，业务n的路径计算，计算之后的处理过程与上述相同，在此不再赘述；
步骤S219，发送业务n的BARRIER_REQUEST；
步骤S220，发送业务1的SNC1交叉响应；
步骤S221，发送业务1的SNC2交叉响应；
步骤S222，发送业务1的SNC1交叉响应；
步骤S223，发送业务1的SNC1映射响应；
步骤S224，发送业务1的SNC2交叉响应；
步骤S225，发送业务1的SNC2映射响应；
步骤S226，发送业务1的BARRIER_REPLY消息；
步骤S227，发送业务n的SNC1交叉响应；
步骤S228，发送业务n的SNC2交叉响应；
步骤S229，发送业务n的SNC1交叉响应；
步骤S230，发送业务n的SNC1映射响应；
步骤S231，发送业务n的SNC2交叉响应；
步骤S232，发送业务n的SNC2映射响应；
步骤S233，发送业务n的BARRIER_REPLY消息。
在上述方式中，不使用bundle机制进行OTN网络多业务恢复，与分组交换设备不同，基于时隙和波长交换的OTN网络设备在配置时较为复杂。对同一块OTN板卡而言，频繁地进行单次的交叉和映射配置，这种处理方式效率较低，且非常耗时。为了提高配置的效率，可将每一次的交叉和映射配置都合并在一起，一次性下发给板卡进行配置，能够提高板卡的处理效率，耗时减少明显。当OTN网络设备使用基于OFP v1.4.0及以后版本的扩展协议时，可以使用bundle机制来对多条业务的多个SNC交叉进行打包处理，恢复过程的示意图如图3所示：
步骤S301，网络故障上报；
步骤S302，业务1的路径计算；
步骤S303，业务n的路径计算；
步骤S304，发送bundle_open消息，启动bundle机制；
步骤S305，发送open_reply消息，以回应bundle机制开启；
步骤S306，通过flow_mod消息承载bundle_add_1消息，将板卡1的相关交叉配置的信息打包至bundle_add_1进行发送；
步骤S307，通过flow_mod消息承载bundle_add_n消息，将板卡n的相关交叉配置的信息打包至bundle_add_n进行发送；
步骤S308，发送bundle_close消息，以关闭bundle机制；
步骤S309，发送close_reply消息，发送关闭成功的回应消息；
步骤S310，发送bundle_commit消息，该消息用于触发板卡的配置功能，并要求返回配置结果；
步骤S311，发送配置业务1到业务n的多个交叉命令；
步骤S312，板卡1处理交叉配置命令；
步骤S313，配置业务1到业务n的多个映射命令；
步骤S314，板卡n处理交叉配置命令；
步骤S315，配置业务1到业务3的多个交叉命令；
步骤S316，板卡n处理多个交叉命令；
步骤S317，发送交叉响应；
步骤S318，发送映射响应；
步骤S319，发送交叉响应；
步骤S320，commit_reply，返回配置结果至控制器。
在SDN架构下的OTN网络中实现多个业务同时进行恢复，以提高多业务并行恢复性能，缩短业务受损时间，是一个非常严峻的问题，使用上述的bundle机制，可以一定程度上提高处理效率，但信令交互效率低下，同样影响恢复性能。
根据本发明实施例的一个方面，提供了一种SDN架构下多业务的并行恢复方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
图4是根据本发明实施例的一种SDN架构下多业务的并行恢复方法的流程图，如图4所示，该方法包括如下步骤：
步骤S401，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息。
步骤S402，基于接收到的故障告警信息为OTN节点生成对应的配置消息，配置消息用于重新配置OTN节点上的所有故障业务。
步骤S403，发送配置消息至对应的OTN节点。
可选地，可由OTN节点通过配置消息中对应于同一个OTN板卡的配置命令对同一个OTN板卡进行配置。
通过上述实施例，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点，将某一节点的所有的配置相关信息通过一个消息包来发送，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息，上述方法的执行主体可以为OTN网络中的控制器，但不局限于此。
在步骤S402中，基于接收到的故障告警信息为OTN节点生成对应的配置消息包括：根据故障告警信息确定故障业务的恢复路径；确定对应于恢复路径的SNC交叉信息；生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
具体的，根据故障告警信息确定故障业务的恢复路径是指从故障告警信息中获取故障业务的故障位置信息；根据故障位置信息生成故障业务的恢复路径。确定对应于恢复路径的SNC交叉信息是指获取恢复路径的路径信息；将恢复路径的路径信息转化为SNC交叉信息。
可选地，在发送配置消息至对应的OTN节点之后，可以通过如下方式获取配置的结果：发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复方法的方法实施例，如图5所示，该方法包括如下步骤：
步骤S501，发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；
步骤S502，接收SDN控制器下发的配置消息，配置消息用于重新配置故障业务；
步骤S503，按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
通过上述实施例，发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡，某一节点通过接收一个消息包来获取所有的配置相关信息，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息，每条flow_mod消息中携带有多条SNC交叉信息，上述方法的执行主体可以为OTN网络中的OTN节点，OTN节点是指OTN网络设备节点(其相当于OTN网络设备的代理节点)，但不局限于此。
在上述的步骤S503中，按照配置消息的指示重新配置用于执行故障业务的OTN板卡包括：基于配置消息生成一个或多个用于配置OTN板卡的配置命令；将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。通过使用一个配置请求来携带多个业务的配置命令，以达到提高配置效率的目的。
具体地，基于配置消息生成一个或多个用于配置OTN板卡的配置命令可通过如下方式实现：获取配置消息中的一个或多个SNC交叉信息；将一个或多个SNC交叉信息转换为一个或多个配置命令。将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡包括：采用TLV格式生成对应于配置命令的TLV数据包；将用于配置同一个OTN板卡的TLV数据包携带于配置请求中，发送至对应的OTN板卡。
可选地，在按照配置消息的指示重新配置用于执行故障业务的OTN板卡之后，在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
具体地，按照预设信息的指示收集被配置的OTN板卡的配置结果包括：接收OTN板卡发送的用于表示配置失败的信息；接收OTN板卡发送的用于表示配置成功的信息；若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
在上述实施例中，提供了一种基于OpenFlow协议扩展的多业务并行恢复的方法，该方法能够将操作同一个OTN网络设备节点的多条业务的多个SNC交叉放到一个flow_mod消息中进行下发，OTN网络设备节点再根据SNC交叉操作的板卡，将操作同一块板卡的多个同类配置命令放在一个配置请求中进行下发。这样不仅简化了控制器与网络设备之间的信令消息交互，还提高OTN板卡的配置处理效率，从而提高了SDN架构下OTN网络多业务并行恢复的性能，缩短了业务受损时间。如果OTN网络设备执行SNC交叉失败，可使用packet_in消息上报具体哪个SNC交叉执行失败。
下面结合图6详述本申请的实施例，如图6所示：
步骤S601，OTN网络中发生断纤，控制器通过OTN网络设备上报的传送平面故障告警信息(即故障告警信息)，感知到网络故障的具体位置。并根据故障位置，对由于该故障导致受损的业务进行恢复路径计算。
步骤S602，所有受损业务恢复路径计算结束后，分析所有业务的恢复路径，并将路由信息转为SNC交叉信息，具体是分析计算成功的恢复路径，并将各个恢复路径信息转化为多个SNC交叉信息。
步骤S603，根据SNC交叉所操作的OTN网络设备节点，将操作同一个设备侧节点的多个SNC交叉信息通过一个flow_mod消息下发给对应的设备侧节点(即OTN节点)，然后再给对应的设备侧节点下发barrier_request消息用于确认执行结果，并给每个操作的设备侧节点启动信令超时定时器，用于确认barrier_reply响应消息是否超时。信令超时的时间可配置，其默认值为OFP标准规定的最小multipart_reply超时时间，即1秒钟。
步骤S604，OTN网络设备侧节点收到并解析SDN控制器下发的flow_mod消息，并将多个SNC交叉信息转换为多个操作OTN板卡的配置命令。
步骤S605，根据配置命令所操作的各个板卡，对配置命令进行分类。将需要操作同一块板卡的多个同类配置命令，都放在一个配置请求中，再下发给对应板卡，并给每个操作的板卡启动交叉超时定时器。交叉超时时间可配置，本申请根据OTN网络设备动态性能指标，设置交叉超时默认值为500毫秒。
各个设备侧节点收到控制器下发的barrier_request消息后，等待各个板卡返回执行结果后，再响应控制器barrier_reply消息，具体见如下步骤：
步骤S606，收集板卡配置响应，并判断板卡是否执行超时，也即收集各个板卡配置命令的执行结果，并判断交叉超时定时器是否超时，如果是，则按配置失败处理，执行步骤S608，如果否，则执行步骤S607。
步骤S607，判断需要执行操作的所有板卡的各个配置命令是否都返回了的执行结果。如果是，则执行步骤S608，如果否，则重复执行步骤S606。
步骤S608，整理各个板卡的配置命令的SNC交叉执行结果，如果均执行成功，则向控制器响应barrier_reply成功消息，如果有板卡命令执行失败，则向控制器响应barrier_reply失败消息，并通过packet_in消息上报执行失败的SNC ID信息(SNC板卡的标识信息)。
步骤S609，控制器收集各个设备侧节点的SNC交叉执行结果，并判断信令超时定时器是否超时，如果超时，则对该设备侧节点按交叉失败处理。
步骤S610，判断是否所有设备侧节点都返回了SNC交叉执行结果，如果是，则执行步骤S611。如果否，则重复执行步骤S610。
步骤S611，控制器根据各个设备侧节点的交叉配置结果(即响应的消息)，判断各个业务是否恢复成功。如果各个节点都响应barrier_reply成功消息，则各个业务均恢复成功。如果存在设备侧节点响应barrier_reply失败消息，则根据packet_in消息上报的SNC ID信息，判断各个业务的恢复结果，流程结束。
在上述实施例中，基于最新版本的OpenFlow协议做了扩展，将多个SNC交叉配置信息封装在一个flow_mod消息中下发给设备侧节点，提高了南向信令的交互和处理效率。具体扩展内容如下：
在ofp_experimenters_field中增加OFPXMT_EXP_OTN_SNCID的定义，用于标示OXM(数据实体对象与XML节点之间的映射称为OXM)的扩展类型。并定义OFP_OXM_EXP_OTN_SNCID的OXM数据结构如图7所示。
上述的字段“ofp_experimenters_field”是Openflow协议光层协议扩展中“onf2015.569_04”中规定的用于表示具体扩展类型内容的字段，本申请在“onf2015.569_04”协议标准的基础上做了扩展，增加了OTN_SNCID的内容。
字段“OFPXMT_EXP_OTN_SNCID”是本申请为了使一个flow_mod消息中能够携带多个SNC信息，而扩展的Openflow协议所定义的新内容，用于表示SNC交叉的ID值。只有使用这个字段所对应的内容，才能准确的标识和区分各个SNC交叉信息。达到在一个flow_mod消息中携带多个SNC交叉时，能够准确的定位和操作每一个SNC交叉的目的。
需要说明的是，SNC在ITU-T G.8080标准中被定义，中文名称为子网连接，定义内容为：子网连接表示了在同一个子网的边界上，两个子网点之间的动态关系。其实就是指定一个流的入端口和入标签，以及出端口和出标签。有了这些入出信息，就能够配置一个数据流。现有的flow_mod消息，只能携带一个SNC交叉信息，无法携带多个，因为入出端口和标签是分开存储的。本申请扩展了协议，新定义了SNC ID的内容，这样就能够对分别存储的入出端口和标签之间建立联系，从而确保将打散的入出端口和标签，能够有序和准确的组成一个个SNC交叉信息。
在图7中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID。experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示扩展的OXM结构。sncid的取值为设备侧节点的唯一编号，使用sncid对不同的SNC交叉进行编号。根据OpenFlow协议的标准规定，SNC交叉中的信号类型、入端口和入标签需要放在flow_mod消息的match域中，而SNC交叉中的出端口和出标签需要放在flow_mod消息的instructions域中。因此需要分别解析flow_mod消息的match域和instructions域后，才能得到一个完整的SNC交叉信息。
由于要将多个SNC交叉封装在一个flow_mod消息中，因此要使用sncid对不同的SNC交叉进行编号，这样就可以根据sncid的值将分配在match域和instructions域中多个入SNC信息和多个出SNC信息进行一一对应，从而在解析该flow_mod消息能够完整的组合出各个SNC交叉信息。
flow_mod消息填写方法为：match域中通过OTN_SNCID将多个SNC交叉中的信号类型、入端口和入标签信息分别进行编号，并按顺序分别填到多个OXM中。instructions域中也通过OTN_SNCID将多个SNC交叉中的出端口和出标签信息进行区分，并按顺序填写到多个action中。对于同一个SNC而言，match域中sncid的值与instructions域中sncid的值要保持一致，扩展后的flow_mod消息示例如图8所示(图8中的消息含义见与图7相关的描述和flow_mod消息的相关定义)。
在上述实施例中，将对同一块OTN板卡设置的多个同类配置命令，放在一个配置请求中，下发给OTN板卡，提高了板卡的处理效率。
OTN板卡的配置命令包括：交叉、映射、波长指派、波长调谐等，本申请采用TLV格式将多个同类的配置命令放在一个请求中，下发给对应板卡。以交叉配置命令为例，配置请求中携带多个TLV的总长度，每个TLV携带一条具体的交叉命令，内容包括：操作类型，源单板，源支路信息，目的单板，目的支路信息等信息。
在上述实施例中，当OTN网络设备执行配置命令失败时，本申请增加了新的流程，通过扩展后的packet_in(为OpenFlow协议中定义的一类消息)消息上报执行失败的SNC ID信息，用于控制器定位交叉执行失败的业务，使多业务并行恢复过程更加完备。packet_in消息具体扩展内容如下：
在ofp_packet_in_reason中增加OFPR_OTN_CONFIG_SNC_FAIL的定义，表示上报原因为“SNC配置失败”。在packet_in消息的match域中，填写本申请扩展的OXM结构OFP_OXM_EXP_OTN_SNCID，其中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID，experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示是扩展的OXM结构。sncid中填写SNC交叉执行失败的sncid值，扩展后的packet_in消息示例如图9所示。
下面结合具体的实施方式详述本申请的实施例。
初始网络拓扑图如图10所示，该网络为纯ODU层网络，其中有四个OTN网络设备节点，分别为A、B、C、D点。网络中共有5条ODU层链路，链路编号分别为1到5，每条链路的带宽均为100G(ODU4)，在A点和B点之间存在80条无保护的ODU0业务，业务路径都为A点(链路1)到B点。
实施方式1
假设链路1发生故障，80条业务并行恢复成功，如图11所示：
步骤S1101，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都为A点(链路5)到D点(链路4)到B点。
步骤S1102，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1103，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1104，设备侧解析flow_mod，将多个SNC交叉信息转换为多个板卡配置命令，具体是三个设备侧节点分别收到flow_mod消息，并根据扩展的OTN_SNCID分别解析match域和instructions域中的入、出端口和标签信息，并组成各个SNC交叉信息。
步骤S1105，分析各个SNC交叉信息，将每一个SNC交叉信息都转换为一个或多个板卡配置命令，并根据操作的板卡将配置命令进行分类，将操作同一块板卡的多个同类配置命令，都放在一个配置请求中，下发给对应板卡，并启动交叉超时定时器，超时时间为500毫秒。
步骤S1106，收集板卡各个配置命令的执行结果(即配置响应信息)，所有操作的板卡均在500毫秒内响应了执行成功。三个设备侧节点收到barrier_request消息后，向控制器响应barrier_reply成功消息。
步骤S1107，SDN控制器在1秒内，分别收到A、D、B三个OTN网络设备节点响应的barrier_reply成功消息，向控制器响应barrier_reply成功消息。
步骤S1108，各个设备侧节点均返回成功，80条业务并行恢复成功，即80条ODU0业务均恢复成功，流程结束。
实施方式2
假设链路1发生故障，由于设备侧节点交叉执行失败，80条业务部分恢复成功，部分恢复失败，本实施例流程图如图12所示。
步骤S1201，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都为A点(链路5)到D点(链路4)到B点。
步骤S1202，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1203，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1204，设备侧解析flow_mod，将多个SNC交叉信息转换为多个板卡配置命令，具体是三个设备侧节点分别收到flow_mod消息，并根据扩展的OTN_SNCID分别解析match域和instructions域中的入、出端口和标签信息，并组成各个SNC交叉信息。
步骤S1205，分析各个SNC交叉信息，将每一个SNC交叉信息都转换为一个或多个板卡配置命令，并根据操作的板卡将配置命令进行分类，将操作同一块板卡的多个同类配置命令，都放在一个配置请求中，下发给对应板卡，并启动交叉超时定时器，超时时间为500毫秒。
步骤S1206，收集板卡各个配置命令的执行结果(即配置响应信息)，所有操作的板卡均在500毫秒内响应了执行结果，但节点D的部分板卡交叉执行失败。因此三个设备侧节点收到barrier_request消息后，节点A、节点B向控制器响应barrier_reply成功消息，而节点D则向控制器响应barrier_reply失败消息，并根据执行失败的配置命令，将执行失败的SNC ID通过packet_in消息上报给控制器。
步骤S1207，部分板卡响应执行失败，向控制器响应barrier_reply失败消息，并通过packet_in上报失败的SNC ID信息，SDN控制器在1秒之内，分别收到了节点A和节点B响应的barrier_reply成功消息，以及节点D响应的barrier_reply失败消息，并解析节点D上报的packet_in消息中的SNC ID，判断80条ODU0业务哪些恢复成功，哪些恢复失败，流程结束。
步骤S1208，存在交叉执行失败的节点，根据packet_in上报失败的SNC ID信息，判断80条业务哪些恢复成功，哪些恢复失败。
实施方式3
假设链路1发生故障，由于控制器与设备侧之间的南向信令中断，导致信令超时，80条业务并行恢复失败，流程如图13所示。
步骤S1301，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都为A点(链路5)到D点(链路4)到B点。
步骤S1302，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1303，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1304，收集各个节点的响应，节点A和节点B均返回成功，但节点D响应超时，由于控制器与节点D之间的信令发生故障，因此无法收到控制器下发的flow_mod消息和barrier_request消息，节点A和节点B收到flow_mod消息和barrier_request消息，且执行交叉成功，并响应控制器barrier_reply成功消息。
步骤S1305，节点D信令超时，交叉设置失败，判断80条业务均恢复失败，SDN控制器在1秒内，只收到了节点A和节点B的barrier_reply成功消息，但没有收到节点D响应的barrier_reply消息，则认为节点D所有SNC交叉均执行失败，80条ODU0业务并行恢复失败，流程结束。
实施方式4
假设链路1发生故障，由于设备侧节点交叉执行超时，80条业务部分恢复成功，部分恢复失败，流程如图14所示：
步骤S1401，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都为A点(链路5)到D点(链路4)到B点。
步骤S1402，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1403，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1404，设备侧解析flow_mod，将多个SNC交叉信息转换为多个板卡配置命令，具体是三个设备侧节点分别收到flow_mod消息，并根据扩展的OTN_SNCID分别解析match域和instructions域中的入、出端口和标签信息，并组成各个SNC交叉信息。
步骤S1405，分析各个SNC交叉信息，将每一个SNC交叉信息都转换为一个或多个板卡配置命令，并根据操作的板卡将配置命令进行分类，将操作同一块板卡的多个同类配置命令，都放在一个配置请求中，下发给对应板卡，并启动交叉超时定时器，超时时间为500毫秒。
步骤S1406，收集板卡各个配置命令的执行结果，节点D的部分板卡在500毫秒内没有响应执行结果，而其他操作的板卡均响应了成功的执行结果。
步骤S1407，部分板卡响应超时，按配置执行失败处理，板卡配置命令响应超时，则认为配置失败。
步骤S1408，向控制器响应barrier_reply失败消息，并通过packet_in上报失败的SNC ID信息，三个设备侧节点收到barrier_request消息后，节点A和节点B向控制器响应barrier_reply成功消息，而节点D则向控制器响应barrier_reply失败消息，并根据执行超时的配置命令，将执行失败的SNC ID通过packet_in消息上报给控制器。
步骤S1409，存在交叉执行失败的节点，根据packet_in上报失败的SNC ID信息，判断80条业务哪些恢复成功，哪些恢复失败，SDN控制器在1秒内，分别收到了节点A和节点B响应的barrier_reply成功消息，以及节点D响应的barrier_reply失败消息，并解析节点D上报的packet_in消息中的SNC ID，判断80条ODU0业务哪些恢复成功，哪些恢复失败，流程结束。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
本发明实施例中还提供了一种SDN架构下多业务的并行恢复装置。该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图15是根据本发明实施例的一种SDN架构下多业务的并行恢复装置的示意图。如图15所示，该装置可以包括：第一接收单元151、生成单元152以及第一发送单元153。
第一接收单元151用于接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；
生成单元152用于基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；
第一发送单元153用于发送配置消息至对应的OTN节点。
通过上述实施例，第一接收单元接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；生成单元基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；第一发送单元发送配置消息至对应的OTN节点，将某一节点的所有的配置相关信息通过一个消息包来发送，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息。
可选地，生成单元包括：第一确定模块，用于根据故障告警信息确定故障业务的恢复路径；第二确定模块，用于确定对应于恢复路径的SNC交叉信息；第一生成模块，用于生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
具体的，上述的第一确定模块包括：第一获取子模块，用于从故障告警信息中获取故障业务的故障位置信息；生成子模块，用于根据故障位置信息生。
上述的第二确定模块包括：第二获取子模块，用于获取恢复路径的路径信息；转化子模块，用于将恢复路径的路径信息转化为SNC交叉信息。
在上述实施例中，可以通过如下方式获取配置的结果：第一发送单元在发送配置消息至对应的OTN节点之后，还用于发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；装置还包括：第二接收单元，用于接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复装置的实施例，图16是根据本发明实施例的另一种SDN架构下多业务的并行恢复装置的示意图。如图16所示，该装置可以包括：第二发送单元161、第三接收单元162以及配置单元163。
第二发送单元161，用于发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；
第三接收单元162，用于接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；
配置单元163，用于按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
通过上述实施例，第二发送单元发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；第三接收单元接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；配置单元按照配置消息的指示重新配置用于执行故障业务的OTN板卡，某一节点通过接收一个消息包来获取所有的配置相关信息，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息，上述OTN节点是指OTN网络设备节点(其相当于OTN网络设备的代理节点)，但不局限于此。
上述的配置单元包括：第二生成模块，用于基于配置消息生成一个或多个用于配置OTN板卡的配置命令；发送模块，用于将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
具体的，第二生成模块包括：第三获取子模块，用于获取配置消息中的一个或多个SNC交叉信息；转换子模块，用于将一个或多个SNC交叉信息转换为一个或多个配置命令。
可选地，上述装置还可包括：收集单元，用于在按照配置消息的指示重新配置用于执行故障业务的OTN板卡之后，在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；反馈单元，用于将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
具体的，收集单元包括：第一接收模块，用于接收OTN板卡发送的用于表示配置失败的信息；第二接收模块，用于接收OTN板卡发送的用于表示配置成功的信息；处理模块，用于若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
在上述实施例中，提供了一种基于OpenFlow协议扩展的多业务并行恢复方式，能够将操作同一个OTN网络设备节点的多条业务的多个SNC交叉放到一个flow_mod消息中进行下发，OTN网络设备节点再根据SNC交叉操作的板卡，将操作同一块板卡的多个同类配置命令放在一个配置请求中进行下发。这样不仅简化了控制器与网络设备之间的信令消息交互，还提高OTN板卡的配置处理效率，从而提高了SDN架构下OTN网络多业务并行恢复的性能，缩短了业务受损时间。如果OTN网络设备执行SNC交叉失败，可使用packet_in消息上报具体哪个SNC交叉执行失败。
下面结合图6详述本申请的实施例，上述的装置可按照如图6所示的步骤工作：
步骤S601，OTN网络中发生断纤，控制器通过OTN网络设备上报的传送平面故障告警信息，感知到网络故障的具体位置。并根据故障位置，对由于该故障导致受损的业务进行恢复路径计算。
步骤S602，所有受损业务恢复路径计算结束后，分析所有业务的恢复路径，并将路由信息转为SNC交叉信息，具体是分析计算成功的恢复路径，并将各个恢复路径信息转化为多个SNC交叉信息。
步骤S603，根据SNC交叉所操作的OTN网络设备节点，将操作同一个设备侧节点的多个SNC交叉信息通过一个flow_mod消息下发给对应的设备侧节点(即OTN节点)，然后再给对应的设备侧节点下发barrier_request消息用于确认执行结果，并给每个操作的设备侧节点启动信令超时定时器，用于确认barrier_reply响应消息是否超时。信令超时的时间可配置，其默认值为OFP标准规定的最小multipart_reply超时时间，即1秒钟。
步骤S604，OTN网络设备侧节点收到并解析SDN控制器下发的flow_mod消息，并将多个SNC交叉信息转换为多个操作OTN板卡的配置命令。
步骤S605，根据配置命令所操作的各个板卡，对配置命令进行分类。将需要操作同一块板卡的多个同类配置命令，都放在一个配置请求中，再下发给对应板卡，并给每个操作的板卡启动交叉超时定时器。交叉超时时间可配置，本申请根据OTN网络设备动态性能指标，设置交叉超时默认值为500毫秒。
各个设备侧节点收到控制器下发的barrier_request消息后，等待各个板卡返回执行结果后，再响应控制器barrier_reply消息，具体见如下步骤：
步骤S606，收集板卡配置响应，并判断板卡是否执行超时，也即收集各个板卡配置命令的执行结果，并判断交叉超时定时器是否超时，如果是，则按配置失败处理，执行步骤S608，如果否，则执行步骤S607。
步骤S607，判断需要执行操作的所有板卡的各个配置命令是否都返回了的执行结果，如果是，则执行步骤S608，如果否，则重复执行步骤S606。
步骤S608，整理各个板卡的配置命令的SNC交叉执行结果，如果均执行成功，则向控制器响应barrier_reply成功消息，如果有板卡命令执行失败，则向控制器响应barrier_reply失败消息，并通过packet_in消息上报执行失败的SNC ID信息(SNC板卡的标识信息)。
步骤S609，控制器收集各个设备侧节点的SNC交叉执行结果，并判断信令超时定时器是否超时，如果超时，则对该设备侧节点按交叉失败处理。
步骤S610，判断是否所有设备侧节点都返回了SNC交叉执行结果，如果是，则执行步骤S611。如果否，则重复执行步骤S610。
步骤S611，控制器根据各个设备侧节点的交叉配置结果(即响应的消息)，判断各个业务是否恢复成功。如果各个节点都响应barrier_reply成功消息，则各个业务均恢复成功。如果存在设备侧节点响应barrier_reply失败消息，则根据packet_in消息上报的SNC ID信息，判断各个业务的恢复结果，流程结束。
在上述实施例中，基于最新版本的OpenFlow协议，将多个SNC交叉配置信息封装在一个flow_mod消息中下发给设备侧节点，提高了南向信令的交互和处理效率。具体扩展内容如下：
在ofp_experimenters_field中增加OFPXMT_EXP_OTN_SNCID的定义，用于标示OXM(数据实体对象与XML节点之间的映射称为OXM)的扩展类型。并定义OFP_OXM_EXP_OTN_SNCID的OXM数据结构如图7所示。
在图7中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID。experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示扩展的OXM结构。sncid的取值为设备侧节点的唯一编号，使用sncid对不同的SNC交叉进行编号。根据OpenFlow协议的标准规定，SNC交叉中的信号类型、入端口和入标签需要放在flow_mod消息的match域中，而SNC交叉中的出端口和出标签需要放在flow_mod消息的instructions域中。因此需要分别解析flow_mod消息的match域和instructions域后，才能得到一个完整的SNC交叉信息。
由于要将多个SNC交叉封装在一个flow_mod消息中，因此要使用sncid对不同的SNC交叉进行编号，这样就可以根据sncid的值将分配在match域和instructions域中多个入SNC信息和多个出SNC信息进行一一对应，从而在解析该flow_mod消息能够完整的组合出各个SNC交叉信息。
flow_mod消息填写方法为：match域中通过OTN_SNCID将多个SNC交叉中的信号类型、入端口和入标签信息分别进行编号，并按顺序分别填到多个OXM中；instructions域中也通过OTN_SNCID将多个SNC交叉中的出端口和出标签信息进行区分，并按顺序填写到多个action中。对于同一个SNC而言，match域中sncid的值与instructions域中sncid的值要保持一致，扩展后的flow_mod消息示例如图8所示(图8中的消息含义见与图7相关的描述和flow_mod消息的相关定义)。
在上述实施例中，将对同一块OTN板卡设置的多个同类配置命令，放在一个配置请求中，下发给OTN板卡，提高了板卡的处理效率。
OTN板卡的配置命令包括：交叉、映射、波长指派、波长调谐等，本申请采用TLV格式将多个同类的配置命令放在一个请求中，下发给对应板卡。以交叉配置命令为例，配置请求中携带多个TLV的总长度，每个TLV携带一条具体的交叉命令，内容包括：操作类型，源单板，源支路信息，目的单板，目的支路信息等信息。
在上述实施例中，当OTN网络设备执行配置命令失败时，本申请增加了新的流程，通过扩展后的packet_in(OpenFlow协议中定义的一类消息)消息上报执行失败的SNC ID信息，用于控制器定位交叉执行失败的业务，使多业务并行恢复过程更加完备。packet_in消息具体扩展内容如下：
在ofp_packet_in_reason中增加OFPR_OTN_CONFIG_SNC_FAIL的定义，表示上报原因为“SNC配置失败”。在packet_in消息的match域中，填写本申请扩展的OXM结构OFP_OXM_EXP_OTN_SNCID，其中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID，experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示是扩展的OXM结构。sncid中填写SNC交叉执行失败的sncid值，扩展后的packet_in消息示例如图9所示。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。
实施例3
根据本发明的另一个实施例，还提供了一种SDN架构下多业务的并行恢复系统，包括SDN控制器和OTN节点，其中，SDN控制器用于接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息，并基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；OTN节点用于接收SDN控制器发送的配置消息。
可选地，SDN控制器还用于：在发送配置消息至对应的OTN节点之后，发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
该实施例的具体实施方式已在前述实施例中说明，在此不再赘述。
实施例4
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：
S11，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；
S12，基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；
S13，发送配置消息至对应的OTN节点。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
S21，发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；
S22，接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；
S23，按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。