CN112491568A - 面向光传送网的算法服务系统及方法 - Google Patents

Abstract

本发明公开了一种面向光传送网的算法服务系统及方法，包括：转发模块、服务分发器、引擎模块、组件管理器、基础组件层和模型适配器，本发明可以将OTN网络中各种算路服务以基础组件的形式呈现给用户，用户可以灵活、自由的选择需求进行组合。从而实现对OTN网络提供可定制化的差异性服务。

Description

面向光传送网的算法服务系统及方法

技术领域

本发明涉及通信领域，尤其涉及一种面向光传送网的算法服务系统及方法。

背景技术

光传送网(Optical Transport Network，简称OTN)技术，是一种新型光传送技术体制，继承了同步数字体系(Synchronous Digital Hierarchy，简称SDH)网络和波分复用(Wavelength Division Multiplexing，简称WDM)网络的优势，其具有大容量和管控机制良好的优势。OTN可以实现多种粒度的信号的传输、交换、复用等功能。同时，OTN可以支持多种上层业务和协议，是承载光网络重要的组网技术。

OTN网络中，网络模型十分复杂，业务形态多种多样。

网络模型方面，OTN网络需要管理波长或者频谱资源，在端到端路径计算时，需要考虑波长连续性或者频谱连续性的约束。此外，一些光损伤约束，如光信噪比(OpticalSignal Noise Ratio，简称OSNR)、色度色散(Chromatic Dispersion，简称CD)、偏振模色散(Polarization Mode Dispersion，简称PMD)、比特误码率(Bit Error Rate，简称BER)，同样影响着光通道的传输性能。

业务形态方面，OTN网络需要支持光波长通道(Optical Channel，简称OCH)层、光通道数据单元(Optical channel Data Unit，简称ODU)层、虚容器(Virtual Container，简称VC)层、以太网(Ethernet，简称ETH)层、互联网协议(Internet Protocol，简称IP)层等多种业务层级和形态。每一层级的业务，使用网络中不同层级的网络资源，不同层级的网络资源相互关联和影响。此外，每一种业务，根据需求，具有不同的业务优先级和保护层级，其中，保护层级根据是否具有保护路径和重路由功能，从高到低，依次分为钻石级、金级、银级、铜级和铁级。在业务建立和恢复时，受网络故障、用户需求、原连接限制等约束，端到端路径计算需要满足必须经过/避开指定资源、尽量经过/避开指定资源的约束。其中，前述资源可包括节点、链路、共享风险链路组(Shared Risk Link Groups，简称SRLG)、共享风险节点组(Shared Risk Node Groups，简称SRNG)、波长、中继板等。

基于前述介绍，复杂的网络模型、多变的业务形态和约束条件，使得OTN网络内的端到端路径计算变得尤为复杂。因此，端到端的路径计算和网络资源管理是OTN网络管理和控制领域中一项重要的关键技术。

目前，OTN网络的路径计算服务架构，由基于分布式智能控制平面，向着基于软件定义网络(Software Defined Network，简称SDN)的集中式智能控制技术发展；路径计算服务实体由嵌入式单板环境，逐步发展为集中的服务器端，并朝着云服务的方向演进。随着独立服务器和云端计算实体的引入，OTN网络的网络资源管理能力和端到端路径计算能力，得到大幅提升，也使得OTN管控平面可以支持更加多样化的需求。

因此，目前急需一种面向智能OTN网络的，支持灵活策略、约束、算法组合的算法服务系统，实现对OTN网络提供可定制化的差异性服务。

发明内容

本发明实施例提供一种面向光传送网的算法服务系统及方法，以实现对OTN网络提供可定制化的差异性服务。

本发明实施例提供一种面向光传送网的算法服务系统，包括：

转发模块，用于接收算法服务请求，将算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将算法服务请求发给服务分发器；

服务分发器，用于基于相应的子服务和算法服务请求，调用引擎模块中相应的引擎；

引擎模块，用于提供针对端到端算法服务的各种引擎，通过引擎选择与算法服务请求对应的业务层级，并将算法服务请求中的计算策略进行拆分封装，根据计算策略和业务层级调用相应的组件管理器；

各个组件管理器，用于对针对端到端算法服务的各个基础组件进行适配、管理和扩展，根据预设的服务逻辑，调用各基础组件并进行封装；

基础组件层，用于保存针对端到端算法计算的各基础组件，接受组件管理器的调用，基于算路拓扑模型实现端到端的算法服务；

模型适配器，用于屏蔽外部资源模型的差异，与外部的网络资源数据库通信，生成算法服务系统内部使用的算路拓扑模型。

本发明实施例还提供一种面向光传送网的算法服务方法，基于上述面向光传送网的算法服务系统，具体包括：

转发模块接收算法服务请求，将算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将算法服务请求发给服务分发器；

服务分发器基于相应的子服务和算法服务请求，调用引擎模块中相应的引擎；通过引擎选择与算法服务请求对应的业务层级，并将算法服务请求中的计算策略进行拆分封装，根据计算策略和业务层级调用相应的组件管理器，通过各组件管理器封装的基础组件，基于模型适配器生成的算路拓扑模型实现端到端的算法服务。

本发明实施例还提供一种面向光传送网的算法服务设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，计算机程序被处理器执行时实现如上述面向光传送网的算法服务方法的步骤。

本发明实施例还提供一种一种计算机可读存储介质，计算机可读存储介质上存储有信息传递的实现程序，程序被处理器执行时实现上述的面向光传送网的算法服务方法的步骤。

采用本发明实施例，可以将OTN网络中各种算路服务以基础组件的形式呈现给用户，用户可以灵活、自由的选择需求进行组合。从而实现对OTN网络提供可定制化的差异性服务。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1是本发明实施例的面向光传送网的算法服务系统的架构示意图；

图2是本发明实例的面向光传送网的算法服务系统的算法服务流程图；

图3是本发明实例的路由计算过程基础组件调用逻辑图；

图4是本发明实例的算法服务系统服务组合示意图；

图5是本发明实例的算法服务系统接入外部路由算法服务流程图；

图6是本发明实例的算法服务系统接入外部标签分配算法服务流程图；

图7是本发明实例的算法服务系统接入外部判决算法服务流程图；

图8是本发明实施例的面向光传送网的算法服务方法的流程图；

图9是本发明装置实施例的面向光传送网的算法服务设备的示意图。

具体实施方式

介于现有技术中存在的问题，各网络使用者和管理者对OTN网络提出了定制化、个性化的需求。同时，部分网络使用者和管理者希望能够开放部分OTN网络开发权限，接入第三方独立开发的功能。因此，有必要设计一套面向智能OTN网络的，支持灵活策略、约束、算法组合的算法服务系统，实现对OTN网络提供可定制化的差异性服务，同时提供部分开放的接口，支持第三方对OTN管控系统在可控制范围内进行有限扩展。

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

系统实施例

根据本发明实施例，提供了一种面向光传送网的算法服务系统，图1是本发明实施例的面向光传送网的算法服务系统的架构示意图，本系统通过外部接口代理10获取外部的算法服务请求，通过模型适配器80，与外部的网络资源数据库通信，生成算法平台内部使用的算路拓扑模型。业务编排器20，基于外部发来的算法服务请求，分发到不同的子服务。各子服务通过服务分发器40，基于业务请求信息，选择对应的业务层级化引擎51和策略引擎52，实现灵活的业务层级和策略的组合。不同的组件管理器60，构建出不同的基础组件搭配策略和使用逻辑，实现不同引擎的要求。特别的，该系统架构，引入了外部接口90，支持外部算法91通过外部接口90接入到系统中。

以下对本发明实施例的系统中的各个模块进行详细说明。

如图1所示，根据本发明实施例的面向光传送网的算法服务系统具体包括：

转发模块，用于接收算法服务请求，将所述算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将所述算法服务请求发给服务分发器；具体地，所述转发模块具体包括：

外部接口代理模块10，用于接收算法服务请求，将所述算法服务请求转换为内部标准格式，转发给业务编排器；

业务编排器20，用于将所述算法服务请求发送到子服务层中相应的子服务；

子服务层30，用于保存针对端到端算法服务需求的子服务，相应的子服务将所述算法服务请求发给服务分发器。

以下对进行具体说明：

外部接口代理模块10，用于接收外部发送的算法服务请求，将算法服务请求转换为内部标准格式，转发给业务编排器；也就是说，外部接口代理模块10是整个系统的对外接口和系统边界，接受外部的算法服务请求，可以屏蔽算法服务请求的来源以及差异性，生成系统内部通用的请求结构。算法服务请求具体包括：业务的基本服务类型、业务层级、业务等级、以及计算策略。

在本发明实施例中，外部用户可以自行选择服务类型，并搭配不同的业务层级和计算策略，实现需求的灵活、个性化组合的方式。

如图4所示，算法服务平台的用户，可根据自身需求，灵活选择需求，组成算法服务请求，具体步骤如下：

步骤一，选择一种服务类型，即业务的基本服务种类，包括但不限于：业务建立、业务恢复、BoD、OVPN、日志。大部分服务类型可以直接对应算法服务系统的子服务，个别的如，业务建立和业务恢复，都可以对应于路由计算子服务。

步骤二，选择一个业务层级。如果是算路相关的算法服务请求，需要选择一个业务层级，包括但不限于：OCH、ODU、VC、以太网、OAC等。

步骤三，选择业务等级，目前业界常用的业务等级包括：钻石级、金级、银级、铜级和铁级。不同的业务等级和业务层级相组合，会形成不同的保护和恢复方法和策略。

步骤四，选择计算策略。计算策略包括优先级、实现类型和资源类型三个属性。每一个策略由上述三个属性的组合而成。本步骤中，用户可以不选择，也可以选择一个或者多个计算策略进行组合。多个计算策略下，策略之间不能冲突，同时，应对每一个策略给出需要满足的优先级。在策略组合中，属性为必须的策略，优先级一定高于属性为尽量满足的策略。此外，用户在选择计算策略时，还能选择是否指定使用特定的算法等额外要求。

步骤五，对上述选择的服务类型、业务层级、业务等级和计算策略进行组合，形成一个完整的算法服务请求。

业务编排器20，用于将算法服务请求发送到子服务层30中相应的子服务；也就是说，业务编排器20需要根据算法服务请求，进行请求的分发和导引。

子服务层30，用于保存针对端到端算法服务需求的子服务，即存放着各种已经实现的、并预留未来可能新加入的端到端算法服务需求的子服务。相应的子服务将算法服务请求发给服务分发器40；完成后续个性化服务和需求的组装。子服务层30包括了OTN网络中各种已实现的成熟的子服务，以及后续可能添加的子服务种类。目前，OTN网络中，常见的子服务有端到端路径计算31、按需分配带宽业务32(Bandwidth on Demand，简称BoD)、光虚拟专用网络33(Optical Virtual Private Network，简称OVPN)和网络日志34，以及其他各种子服务。

服务分发器40，用于基于相应的子服务和算法服务请求，调用引擎模块50中相应的引擎；

引擎模块50，用于提供针对端到端算法服务的各种引擎，通过引擎选择与算法服务请求对应的业务层级，并将算法服务请求中的计算策略进行拆分封装，根据计算策略和业务层级调用相应的组件管理器60；引擎模块50提供了可用于算路服务的各种引擎中间件，其中包括但不仅限于：基于业务层次的业务层级化引擎51，调度、处理基础算法组件完成复杂策略、约束等用户需求的策略引擎52。引擎层是服务分发器40的直接处理对象。

进一步的，引擎模块50具体包括：

业务层级化引擎51，用于响应于服务分发器的调用，选择与算法服务请求对应的业务层级；业务层级化引擎51包含了不同层级的算法服务需求，目前SDN场景中常见的OCH、ODU、VC、以太网等业务均在其中。此外，随着后续需求的扩展，将会引入更加丰富的业务层次计算。

策略引擎52，用于响应于服务分发器的调用，将算法服务请求中的计算策略进行拆分封装；策略引擎52包含了不同的路由计算策略(也称为路由计算约束)。路由计算约束可以从优先级、实现类型和资源类型三个角度进行描述。目前SDN场景中常见的路由计算约束按照优先级可以分为必须和尽量两种：必须满足的约束条件，要求路由结果必须无条件满足，否则失败；尽量的含义为在存在路由结果的前提下，优先选择符合约束条件的结果。路由计算约束按照实现类型可以分为经过(使用)和避开两类：经过的含义为使用相关的资源；避开的含义为不适用相关的资源。资源类型可以分为节点资源、链路资源、SRLG、SRNG、波长资源、中继板资源、光损伤约束等。算法服务的完整计算策略可以是上述策略的一种或者多种组合，例如，某请求可以包含必须经过某节点，又必须排除另一个节点，尽量经过某一条链路，并且尽量避开另一条链路。原则上，相关约束不能相互冲突，即不能存在某请求必须经过某一资源，同时必须或者尽量排除该资源。在本系统中，策略引擎52仅做策略的拆分，校验工作由基础组件层70中的请求分析71完成。

调用模块53，用于根据计算策略和业务层级调用相应的组件管理器60。也就是说，调用模块53需要综合考虑计算策略和业务层级，从而调用合适的组件管理器60。

各个组件管理器60，用于对针对端到端算法服务的各个基础组件进行适配、管理和扩展，根据预设的服务逻辑，调用各基础组件并进行封装；其中，预设的服务逻辑是根据经验设置的服务逻辑。

也就是说管理器层60为了适配上层引擎层50中，各个中间件差异化算路的需求，而对基础组件的适配、管理以及扩展，由于基础组件基本是业务无关、模型无关的，为了满足中间件中各项具体的业务需求，非常有必要对各项基本组件进行二次封装和扩展，这些工作将在管理器层60完成。同时，该层还可以对外提供外部基础组件(可能来自具体运营商)接口及封装工作，提升基础组件的对外扩展性和灵活性。

基础组件层70，用于保存针对端到端算法计算的各基础组件，接受组件管理器的调用，基于算路拓扑模型实现端到端的算法服务；基础组件层70管理着剥离出来的最基础的算路组件，包括但不限于：请求分析71、拓扑处理72、算法库73、资源占用74、消息回复75、日志记录76、标签分配77、资源释放78等。各基础组件均为无状态、功能独立、业务无关、模型无关的组件，给定输入参数，实现上述基础功能。

在本发明实施例中，基础组件具体包括：

请求分析模块71，用于对算法服务请求进行分析，校验相关原宿节点参数，对于存在路由约束冲突的算法服务请求，基于已有规则，对路由约束进行改造；请求分析模块71具体用于：对算法服务请求进行分析，校验原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持、以及业务场景是否支持，如果校验失败则将进入路由计算失败处理流程，如果校验成功则允许执行拓扑处理。

拓扑处理模块72，用于基于已有的路由约束，对网络资源数据库的算路拓扑模型进行改造，删除一些不必要的资源信息，保留必要的资源信息，形成最简算路拓扑模型；拓扑处理模块72具体用于：基于业务层级化引擎和策略引擎解析的业务层级和计算策略，对算路拓扑模型进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑。

算法库73，用于保存算法服务系统内的基础算法，基于最简算路拓扑模型，通过基础算法进行路由计算；基础算法包括但不限于：端到端受限路径计算算法、光损伤算法等。算法库本身是高度抽象是的算法集合，所有算法均做到业务无关、模型无关。

资源占用模块74，用于在完成路由计算后，基于路由计算结果，进行网络资源数据库中相应资源的占用和修改；

消息回复模块75，用于向算法服务请求发起方返回路由计算结果；

日志记录模块76，用于记录每一个基础组件运行流程和结果；该组件可由外部命令控制是否开启。

标签分配模块77，用于为未分配资源的路由计算结果分配网络资源；

资源释放模块78，用于释放某条指定路由占用的资源。

模型适配器80，用于屏蔽外部资源模型的差异，与外部的网络资源数据库通信，生成算法平台内部使用的算路拓扑模型。

在本发明实施中，端到端路由计算功能是算法服务平台最重要的功能，是多种子服务(包括但不限于：路由计算、BoD、OPVN等)的核心功能。网络日志等其他子服务，作为可测试性、可维护性的表现，也是重要的子服务，存在于算法服务平台内。所有的端到端算法服务，均可以看作是基于基础组件的不同逻辑调用方式，实现不同的子服务类型和计算策略。

图3是端到端路由计算过程各基础组件调用逻辑图。整个端到端的路径计算，步骤如下：

步骤一，由请求分析模块71处理，分析请求的合法性，包括但不限于：原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持，业务场景是否支持。如果成功，将进行拓扑处理，失败将进入路由计算失败流程。

步骤二，拓扑处理模块72基于业务层级化引擎和计算策略引擎解析的业务层级化信息和路由约束信息，对网络资源拓扑进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑，传递给后续基础组件。

步骤三，路径计算过程由算法库73的基础组件承担，组件管理器60通过选择算法库73中合适的子组件，基于前述网络资源拓扑，完成路径计算过程。如果成功，将标签分配，失败将进入路由计算失败流程。

步骤四，标签分配过程由标签分配模块77完成，在路径计算结果的基础上，分配符合网络规则、计算策略的标签资源。该过程如果失败，将返回算法库73的基础组件重新计算一条路径，成功，则进入下一流程。

步骤五，标签分配成功后，将依次资源占用模块74和消息回复模块75，完成相应的操作，并进入成功流程，完成整个端到端的计算服务。如果是失败流程，无论是从哪一个分支出来的失败，消息回复组件也将基于失败情况，回复相应的失败消息。

图2是本发明实例的系统的算法服务流程图，系统的各个模块包括如下处理：

步骤101，算法服务平台通过接口代理模块10接收到来自外部模块的算法服务请求，并转换成算法服务平台内的标准格式请求，转发给业务编排器20。

步骤102，业务编排器20收到算法服务请求后，找到子服务层30对应的子服务，并发送给相应的子服务。

步骤103，子服务将请求转发给服务分发器40，服务分发器40基于相应的子服务和算法服务请求，调用引擎模块50中相应的引擎

步骤104，在业务层级化引擎51内对业务请求进行初步拆分，在业务层级化引擎内，根据业务场景、信息，选择对应的业务层级，如OCH、ODU、VC或者以太网等。在策略引擎52将请求中包含的计算策略进行拆分，封装成标准数据结构，以服务文本形式存下，并发给相应的组件管理器60。

步骤105，各组件管理器60根据预设的服务逻辑(即决定调用哪些并如何调用各基础组件)，会预先调用各基础组件并进行封装好，等待引擎模块50的调用。

步骤106，各组件管理器60依自身逻辑，依次调用各基础组件，实现端到端的算法服务。其中，请求分析、资源数据库更新、消息回复等操作，均在基础组件内完成。

在本发明实施例中，部分网络使用者和管理者希望能够开放部分OTN网络开发权限，接入第三方独立开发的功能。因此，在本发明实施例中，同时提供部分开放的接口，支持第三方对OTN管控系统在可控制范围内进行有限扩展，因此，上述系统进一步包括：

外部接口90，用于预留给外部用户，如运营商、第三方使用者等，接入外部基础组件91(即外部算法)，通过管理层60的组合和调度，实现与系统内部基础组件的替代与复用。

以下结合实例对通过外接基础组件实现算路服务的实施例进行说明。

实例1，

本发明实施例提供了一种外部用户接入外部路由算法实现算法服务的方式。

图5给出了算法服务系统接入外部路由算法服务流程图，外部算法作为一个基础组件，接入到算法服务系统中，其中最短路径算法作为端到端路径计算流程中的一个基础组件。具体步骤如下：

步骤一，用户通过外部接口接入外部的面向路由计算的最短路径计算算法，形成外部算法基础组件。未在图5中示出。

步骤二，在外部接口，形成消息的适配，将算法服务系统内部消息与外部算法需要的消息进行格式转换。未在图5中示出。

步骤三，在上述架构下，发起端到端路由计算请求，依次进行请求分析、拓扑处理。

步骤四，算法服务系统通过外部端口，发送拓扑处理后的拓扑信息和请求分析后的路由请求。通过外部接口，转换成外部路由算法需要的消息结构。

步骤五，外部算法组件，基于自身逻辑，通过输入的拓扑信息和路由请求，完成计算过程，输出路由结果。

步骤六，外部接口接收外部算法组件输出的路由结果，转换成符合算法服务系统内部的消息结构。

步骤七，算法服务系统，基于路由计算结果，继续进行标签分配、资源占用和消息回复的流程，完成整个端到端的路由计算流程。

实例2,

在一些应用场景下，算法服务系统用户对标签分配过程，有着不同的需求，会自定义标签分配的算法，本发明实施例提供了一种外部用户接入外部标签分配算法实现算法服务的方式。

图6给出了算法服务系统接入外部标签分配算法服务流程图，外部标签分配算法作为一个基础组件，接入到算法服务系统中。具体步骤如下：

步骤一，用户通过外部接口接入外部的面向给定路由结果的标签分配算法，形成外部算法基础组件。未在图6中示出。

步骤二，在外部接口，形成消息的适配，将算法服务系统内部消息与外部算法需要的消息进行格式转换。未在图6中示出。

步骤三，在上述架构下，发起端到端路由计算请求，依次进行请求分析、拓扑处理、路由计算。

步骤四，算法服务系统通过外部端口，发送路由结果和路由结果关联的资源信息。通过外部接口，转换成外部路由算法需要的消息结构。

步骤五，外部算法组件，基于自身逻辑，通过输入的路由结果和资源信息，完成标签分配过程，输出标签分配结果。

步骤六，外部接口接收外部算法组件输出的路由结果，转换成符合算法服务系统内部的消息结构。

步骤七，算法服务系统，基于标签分配结果，继续进行资源占用和消息回复的流程，完成整个端到端的路由计算流程。

实例3

在一些应用场景下，算法服务系统的用户在路由计算过程中，会自定义加入一些额外的判决条件，如WSS穿通门限，指定路径偏好等，可以在算法服务系统中接入外部判决算法。

图7给出了算法服务系统接入外部判决算法服务流程图，外部判决算法作为一个基础组件，接入到算法服务系统中。具体步骤如下：

步骤一，用户通过外部接口接入外部的面向给定路由结果的判决算法，形成外部算法基础组件。

步骤二，在外部接口，形成消息的适配，将算法服务系统内部消息与外部算法需要的消息进行格式转换。

步骤三，在上述架构下，发起端到端路由计算请求，依次进行请求分析、拓扑处理、路由计算、标签分配。

步骤四，算法服务系统通过外部端口，发送标签分配后的完整路由结果。通过外部接口，转换成外部路由算法需要的消息结构。

步骤五，外部判决算法组件，基于自身逻辑，通过输入的路由结果，完成判决过程，输出判决结果。

步骤六，外部接口接收外部算法组件输出的判决结果，返回给算法服务系统。

步骤七，算法服务系统，基于判决结果，如果判决失败，则重新选路，判决成功，则进入资源占用和消息回复流程，完成整个端到端的路由计算过程。

综上所述，借助于本发明实施例的技术方案与现有技术相比较，本发明实施例可以将OTN网络中各种算路服务以基础组件的形式呈现给用户，用户可以灵活、自由的选择需求进行组合。同时，该系统创新性的提出了可以接入第三方算法的服务提供方式。

方法实施例

根据本发明实施例，提供了一种面向光传送网的算法服务方法，基于系统实施例中的面向光传送网的算法服务系统，图8是本发明实施例的面向光传送网的算法服务方法的流程图，如图8所示，该方法具体包括：

步骤801，转发模块接收算法服务请求，将所述算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将所述算法服务请求发给服务分发器；

具体包括如下处理：

步骤1，外部接口代理模作为整个系统的对外接口和系统边界，接收外部发送的算法服务请求，将所述算法服务请求转换为内部标准格式，转发给业务编排器；也就是说，外部接口代理模块接受外部的算法服务请求，可以屏蔽算法服务请求的来源以及差异性，生成系统内部通用的请求结构。算法服务请求具体包括：业务的基本服务类型、业务层级、业务等级、以及计算策略。

在本发明实施例中，外部用户可以自行选择服务类型，并搭配不同的业务层级和计算策略，实现需求的灵活、个性化组合的方式。

如图4所示，算法服务平台的用户，可根据自身需求，灵活选择需求，组成算法服务请求，具体步骤如下：

步骤一，选择一种服务类型，即业务的基本服务种类，包括但不限于：业务建立、业务恢复、BoD、OVPN、日志。大部分服务类型可以直接对应算法服务系统的子服务，个别的如，业务建立和业务恢复，都可以对应于路由计算子服务。

步骤二，选择一个业务层级。如果是算路相关的算法服务请求，需要选择一个业务层级，包括但不限于：OCH、ODU、VC、以太网、OAC等。

步骤三，选择业务等级，目前业界常用的业务等级包括：钻石级、金级、银级、铜级和铁级。不同的业务等级和业务层级相组合，会形成不同的保护和恢复方法和策略。

步骤四，选择计算策略。计算策略包括优先级、实现类型和资源类型三个属性。每一个策略由上述三个属性的组合而成。本步骤中，用户可以不选择，也可以选择一个或者多个计算策略进行组合。多个计算策略下，策略之间不能冲突，同时，应对每一个策略给出需要满足的优先级。在策略组合中，属性为必须的策略，优先级一定高于属性为尽量满足的策略。此外，用户在选择计算策略时，还能选择是否指定使用特定的算法等额外要求。

步骤五，对上述选择的服务类型、业务层级、业务等级和计算策略进行组合，形成一个完整的算法服务请求。

步骤2，业务编排器将所述算法服务请求发送到子服务层中相应的子服务；业务编排器需要根据算法服务请求，进行请求的分发和导引。

步骤3，相应的子服务将所述算法服务请求发给服务分发器；常见的子服务有端到端路径计算、按需分配带宽业务(Bandwidth on Demand，简称BoD)、光虚拟专用网络(Optical Virtual Private Network，简称OVPN)和网络日志，以及其他各种子服务。

步骤802，所述服务分发器基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器，通过各组件管理器封装的基础组件，基于模型适配器生成的算路拓扑模型实现端到端的算法服务。

步骤802具体包括如下处理：

步骤1，所述服务分发器基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；

步骤2，通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器；引擎模块提供了可用于算路服务的各种引擎中间件，其中包括但不仅限于：基于业务层次的业务层级化引擎，调度、处理基础算法组件完成复杂策略、约束等用户需求的策略引擎。引擎层是服务分发器的直接处理对象。步骤805具体包括如下处理：

业务层级化引擎响应于服务分发器的调用，选择与算法服务请求对应的业务层级；业务层级化引擎包含了不同层级的算法服务需求，目前SDN场景中常见的OCH、ODU、VC、以太网等业务均在其中。此外，随着后续需求的扩展，将会引入更加丰富的业务层次计算。

策略引擎响应于服务分发器的调用，将算法服务请求中的计算策略进行拆分封装；策略引擎包含了不同的路由计算策略(也称为路由计算约束)。路由计算约束可以从优先级、实现类型和资源类型三个角度进行描述。目前SDN场景中常见的路由计算约束按照优先级可以分为必须和尽量两种：必须满足的约束条件，要求路由结果必须无条件满足，否则失败；尽量的含义为在存在路由结果的前提下，优先选择符合约束条件的结果。路由计算约束按照实现类型可以分为经过(使用)和避开两类：经过的含义为使用相关的资源；避开的含义为不适用相关的资源。资源类型可以分为节点资源、链路资源、SRLG、SRNG、波长资源、中继板资源、光损伤约束等。算法服务的完整计算策略可以是上述策略的一种或者多种组合，例如，某请求可以包含必须经过某节点，又必须排除另一个节点，尽量经过某一条链路，并且尽量避开另一条链路。原则上，相关约束不能相互冲突，即不能存在某请求必须经过某一资源，同时必须或者尽量排除该资源。在本系统中，策略引擎仅做策略的拆分，校验工作由基础组件层中的请求分析完成。

调用模块根据计算策略和业务层级调用相应的组件管理器。也就是说，调用模块需要综合考虑计算策略和业务层级，从而调用合适的组件管理器。

步骤3，各组件管理器对针对端到端算法服务的各个基础组件进行适配、管理和扩展，根据预设的服务逻辑，调用各基础组件并进行封装；其中，预设的服务逻辑是根据经验设置的服务逻辑。

也就是说管理器层为了适配上层引擎层中，各个中间件差异化算路的需求，而对基础组件的适配、管理以及扩展，由于基础组件基本是业务无关、模型无关的，为了满足中间件中各项具体的业务需求，非常有必要对各项基本组件进行二次封装和扩展，这些工作将在管理器层完成。同时，该层还可以对外提供外部基础组件(可能来自具体运营商)接口及封装工作，提升基础组件的对外扩展性和灵活性。

步骤4，模型适配器屏蔽外部资源模型的差异，与外部的网络资源数据库通信，生成算法平台内部使用的算路拓扑模型；

步骤5，各基础组件接受所述组件管理器的调用，基于算路拓扑模型实现端到端的算法服务。具体包括如下处理：

1、通过请求分析模块对所述算法服务请求进行分析，校验相关原宿节点参数，对于存在路由约束冲突的算法服务请求，基于已有规则，对路由约束进行改造；具体地，通过请求分析模块对所述算法服务请求进行分析，校验原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持、以及业务场景是否支持，如果校验失败则将进入路由计算失败处理流程，如果校验成功则允许执行拓扑处理。

2、通过拓扑处理模块，基于已有的路由约束，对网络资源数据库的算路拓扑模型进行改造，保留必要的资源信息，形成最简算路拓扑模型；具体地，通过拓扑处理模块基于业务层级化引擎和策略引擎解析的业务层级和计算策略，对算路拓扑模型进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑。

3、通过算法库保存算法服务系统内的基础算法，基于所述最简算路拓扑模型，通过所述基础算法进行路由计算；

4、在完成路由计算后，通过资源占用模块基于路由计算结果，进行网络资源数据库中相应资源的占用和修改；

5、通过消息回复模块向算法服务请求发起方返回路由计算结果；

6、通过日志记录模块记录每一个基础组件运行流程和结果；

7、通过标签分配模块为未分配资源的路由计算结果分配网络资源；

8、通过资源释放模块释放某条指定路由占用的资源。

在本发明实施中，端到端路由计算功能是算法服务平台最重要的功能，是多种子服务(包括但不限于：路由计算、BoD、OPVN等)的核心功能。网络日志等其他子服务，作为可测试性、可维护性的表现，也是重要的子服务，存在于算法服务平台内。所有的端到端算法服务，均可以看作是基于基础组件的不同逻辑调用方式，实现不同的子服务类型和计算策略。

图3是端到端路由计算过程各基础组件调用逻辑图。整个端到端的路径计算，步骤如下：

步骤一，由请求分析模块处理，分析请求的合法性，包括但不限于：原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持，业务场景是否支持。如果成功，将进行拓扑处理，失败将进入路由计算失败流程。

步骤二，拓扑处理模块基于业务层级化引擎和计算策略引擎解析的业务层级化信息和路由约束信息，对网络资源拓扑进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑，传递给后续基础组件。

步骤三，路径计算过程由算法库的基础组件承担，组件管理器通过选择算法库73中合适的子组件，基于前述网络资源拓扑，完成路径计算过程。如果成功，将标签分配，失败将进入路由计算失败流程。

步骤四，标签分配过程由标签分配模块完成，在路径计算结果的基础上，分配符合网络规则、计算策略的标签资源。该过程如果失败，将返回算法库的基础组件重新计算一条路径，成功，则进入下一流程。

步骤五，标签分配成功后，将依次资源占用模块和消息回复模块，完成相应的操作，并进入成功流程，完成整个端到端的计算服务。如果是失败流程，无论是从哪一个分支出来的失败，消息回复组件也将基于失败情况，回复相应的失败消息。

如图2所示，本发明实施例的上述处理可以参照以下处理步骤理解：

步骤101，算法服务平台通过接口代理模块接收到来自外部模块的算法服务请求，并转换成算法服务平台内的标准格式请求，转发给业务编排器。

步骤102，业务编排器收到算法服务请求后，找到子服务层对应的子服务，并发送给相应的子服务。

步骤103，子服务将请求转发给服务分发器，服务分发器基于相应的子服务和算法服务请求，调用引擎模块中相应的引擎

步骤104，在业务层级化引擎内对业务请求进行初步拆分，在业务层级化引擎内，根据业务场景、信息，选择对应的业务层级，如OCH、ODU、VC或者以太网等。在策略引擎将请求中包含的计算策略进行拆分，封装成标准数据结构，以服务文本形式存下，并发给相应的组件管理器。

步骤105，各组件管理器根据预设的服务逻辑(即决定调用哪些并如何调用各基础组件)，会预先调用各基础组件并进行封装好，等待引擎模块中调用模块根据计算策略和业务层级对相应组件管理器的调用。

步骤106，各组件管理器依自身逻辑，依次调用各基础组件，实现端到端的算法服务。其中，请求分析、资源数据库更新、消息回复等操作，均在基础组件内完成。

在本发明实施例中，部分网络使用者和管理者希望能够开放部分OTN网络开发权限，接入第三方独立开发的功能。因此，在本发明实施例中，同时提供部分开放的接口，支持第三方对OTN管控系统在可控制范围内进行有限扩展，因此，在本发明实施例中，所述方法进一步包括：

通过外部接口接入外部基础组件，实现与系统内部基础组件的替代与复用。

以下结合实例对通过外接基础组件实现算路服务的实施例进行说明。

实例1，

本发明实施例提供了一种外部用户接入外部路由算法实现算法服务的方式。

图5给出了算法服务系统接入外部路由算法服务流程图，外部算法作为一个基础组件，接入到算法服务系统中，其中最短路径算法作为端到端路径计算流程中的一个基础组件。具体步骤如下：

步骤一，用户通过外部接口接入外部的面向路由计算的最短路径计算算法，形成外部算法基础组件。

步骤二，在外部接口，形成消息的适配，将算法服务系统内部消息与外部算法需要的消息进行格式转换。

步骤三，在上述架构下，发起端到端路由计算请求，依次进行请求分析、拓扑处理。

步骤四，算法服务系统通过外部端口，发送拓扑处理后的拓扑信息和请求分析后的路由请求。通过外部接口，转换成外部路由算法需要的消息结构。

步骤五，外部算法组件，基于自身逻辑，通过输入的拓扑信息和路由请求，完成计算过程，输出路由结果。

步骤六，外部接口接收外部算法组件输出的路由结果，转换成符合算法服务系统内部的消息结构。

步骤七，算法服务系统，基于路由计算结果，继续进行标签分配、资源占用和消息回复的流程，完成整个端到端的路由计算流程。

实例2,

在一些应用场景下，算法服务系统用户对标签分配过程，有着不同的需求，会自定义标签分配的算法，本发明实施例提供了一种外部用户接入外部标签分配算法实现算法服务的方式。

图6给出了算法服务系统接入外部标签分配算法服务流程图，外部标签分配算法作为一个基础组件，接入到算法服务系统中。具体步骤如下：

步骤一，用户通过外部接口接入外部的面向给定路由结果的标签分配算法，形成外部算法基础组件。

步骤二，在外部接口，形成消息的适配，将算法服务系统内部消息与外部算法需要的消息进行格式转换。

步骤三，在上述架构下，发起端到端路由计算请求，依次进行请求分析、拓扑处理、路由计算。

步骤四，算法服务系统通过外部端口，发送路由结果和路由结果关联的资源信息。通过外部接口，转换成外部路由算法需要的消息结构。

步骤五，外部算法组件，基于自身逻辑，通过输入的路由结果和资源信息，完成标签分配过程，输出标签分配结果。

步骤六，外部接口接收外部算法组件输出的路由结果，转换成符合算法服务系统内部的消息结构。

步骤七，算法服务系统，基于标签分配结果，继续进行资源占用和消息回复的流程，完成整个端到端的路由计算流程。

实例3

在一些应用场景下，算法服务系统的用户在路由计算过程中，会自定义加入一些额外的判决条件，如WSS穿通门限，指定路径偏好等，可以在算法服务系统中接入外部判决算法。

图7给出了算法服务系统接入外部判决算法服务流程图，外部判决算法作为一个基础组件，接入到算法服务系统中。具体步骤如下：

步骤一，用户通过外部接口接入外部的面向给定路由结果的判决算法，形成外部算法基础组件。

步骤二，在外部接口，形成消息的适配，将算法服务系统内部消息与外部算法需要的消息进行格式转换。

步骤三，在上述架构下，发起端到端路由计算请求，依次进行请求分析、拓扑处理、路由计算、标签分配。

步骤四，算法服务系统通过外部端口，发送标签分配后的完整路由结果。通过外部接口，转换成外部路由算法需要的消息结构。

步骤五，外部判决算法组件，基于自身逻辑，通过输入的路由结果，完成判决过程，输出判决结果。

步骤六，外部接口接收外部算法组件输出的判决结果，返回给算法服务系统。

步骤七，算法服务系统，基于判决结果，如果判决失败，则重新选路，判决成功，则进入资源占用和消息回复流程，完成整个端到端的路由计算过程。

综上所述，借助于本发明实施例的技术方案与现有技术相比较，本发明实施例可以将OTN网络中各种算路服务以基础组件的形式呈现给用户，用户可以灵活、自由的选择需求进行组合。同时，该系统创新性的提出了可以接入第三方算法的服务提供方式。

本发明实施例提供一种面向光传送网的算法服务设备，如图9所示，包括：存储器90、处理器92及存储在所述存储器90上并可在所述处理器92上运行的计算机程序，所述计算机程序被所述处理器92执行时实现如下方法步骤：

步骤801，转发模块接收算法服务请求，将所述算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将所述算法服务请求发给服务分发器；

具体包括如下处理：

步骤1，外部接口代理模作为整个系统的对外接口和系统边界，接收外部发送的算法服务请求，将所述算法服务请求转换为内部标准格式，转发给业务编排器；也就是说，外部接口代理模块接受外部的算法服务请求，可以屏蔽算法服务请求的来源以及差异性，生成系统内部通用的请求结构。算法服务请求具体包括：业务的基本服务类型、业务层级、业务等级、以及计算策略。

在本发明实施例中，外部用户可以自行选择服务类型，并搭配不同的业务层级和计算策略，实现需求的灵活、个性化组合的方式。

如图4所示，算法服务平台的用户，可根据自身需求，灵活选择需求，组成算法服务请求，具体步骤如下：

步骤一，选择一种服务类型，即业务的基本服务种类，包括但不限于：业务建立、业务恢复、BoD、OVPN、日志。大部分服务类型可以直接对应算法服务系统的子服务，个别的如，业务建立和业务恢复，都可以对应于路由计算子服务。

步骤二，选择一个业务层级。如果是算路相关的算法服务请求，需要选择一个业务层级，包括但不限于：OCH、ODU、VC、以太网、OAC等。

步骤三，选择业务等级，目前业界常用的业务等级包括：钻石级、金级、银级、铜级和铁级。不同的业务等级和业务层级相组合，会形成不同的保护和恢复方法和策略。

步骤四，选择计算策略。计算策略包括优先级、实现类型和资源类型三个属性。每一个策略由上述三个属性的组合而成。本步骤中，用户可以不选择，也可以选择一个或者多个计算策略进行组合。多个计算策略下，策略之间不能冲突，同时，应对每一个策略给出需要满足的优先级。在策略组合中，属性为必须的策略，优先级一定高于属性为尽量满足的策略。此外，用户在选择计算策略时，还能选择是否指定使用特定的算法等额外要求。

步骤五，对上述选择的服务类型、业务层级、业务等级和计算策略进行组合，形成一个完整的算法服务请求。

步骤2，业务编排器将所述算法服务请求发送到子服务层中相应的子服务；业务编排器需要根据算法服务请求，进行请求的分发和导引。

步骤3，相应的子服务将所述算法服务请求发给服务分发器；常见的子服务有端到端路径计算、按需分配带宽业务(Bandwidth on Demand，简称BoD)、光虚拟专用网络(Optical Virtual Private Network，简称OVPN)和网络日志，以及其他各种子服务。

步骤802，所述服务分发器基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器，通过各组件管理器封装的基础组件，基于模型适配器生成的算路拓扑模型实现端到端的算法服务。

步骤802具体包括如下处理：

步骤1，所述服务分发器基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；

步骤2，通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器；引擎模块提供了可用于算路服务的各种引擎中间件，其中包括但不仅限于：基于业务层次的业务层级化引擎，调度、处理基础算法组件完成复杂策略、约束等用户需求的策略引擎。引擎层是服务分发器的直接处理对象。步骤805具体包括如下处理：

业务层级化引擎响应于服务分发器的调用，选择与算法服务请求对应的业务层级；业务层级化引擎包含了不同层级的算法服务需求，目前SDN场景中常见的OCH、ODU、VC、以太网等业务均在其中。此外，随着后续需求的扩展，将会引入更加丰富的业务层次计算。

策略引擎响应于服务分发器的调用，将算法服务请求中的计算策略进行拆分封装；策略引擎包含了不同的路由计算策略(也称为路由计算约束)。路由计算约束可以从优先级、实现类型和资源类型三个角度进行描述。目前SDN场景中常见的路由计算约束按照优先级可以分为必须和尽量两种：必须满足的约束条件，要求路由结果必须无条件满足，否则失败；尽量的含义为在存在路由结果的前提下，优先选择符合约束条件的结果。路由计算约束按照实现类型可以分为经过(使用)和避开两类：经过的含义为使用相关的资源；避开的含义为不适用相关的资源。资源类型可以分为节点资源、链路资源、SRLG、SRNG、波长资源、中继板资源、光损伤约束等。算法服务的完整计算策略可以是上述策略的一种或者多种组合，例如，某请求可以包含必须经过某节点，又必须排除另一个节点，尽量经过某一条链路，并且尽量避开另一条链路。原则上，相关约束不能相互冲突，即不能存在某请求必须经过某一资源，同时必须或者尽量排除该资源。在本系统中，策略引擎仅做策略的拆分，校验工作由基础组件层中的请求分析完成。

调用模块根据计算策略和业务层级调用相应的组件管理器。也就是说，调用模块需要综合考虑计算策略和业务层级，从而调用合适的组件管理器。

步骤3，各组件管理器对针对端到端算法服务的各个基础组件进行适配、管理和扩展，根据预设的服务逻辑，调用各基础组件并进行封装；其中，预设的服务逻辑是根据经验设置的服务逻辑。

也就是说管理器层为了适配上层引擎层中，各个中间件差异化算路的需求，而对基础组件的适配、管理以及扩展，由于基础组件基本是业务无关、模型无关的，为了满足中间件中各项具体的业务需求，非常有必要对各项基本组件进行二次封装和扩展，这些工作将在管理器层完成。同时，该层还可以对外提供外部基础组件(可能来自具体运营商)接口及封装工作，提升基础组件的对外扩展性和灵活性。

步骤4，模型适配器屏蔽外部资源模型的差异，与外部的网络资源数据库通信，生成算法平台内部使用的算路拓扑模型；

步骤5，各基础组件接受所述组件管理器的调用，基于算路拓扑模型实现端到端的算法服务。具体包括如下处理：

1、通过请求分析模块对所述算法服务请求进行分析，校验相关原宿节点参数，对于存在路由约束冲突的算法服务请求，基于已有规则，对路由约束进行改造；具体地，通过请求分析模块对所述算法服务请求进行分析，校验原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持、以及业务场景是否支持，如果校验失败则将进入路由计算失败处理流程，如果校验成功则允许执行拓扑处理。

2、通过拓扑处理模块，基于已有的路由约束，对网络资源数据库的算路拓扑模型进行改造，保留必要的资源信息，形成最简算路拓扑模型；具体地，通过拓扑处理模块基于业务层级化引擎和策略引擎解析的业务层级和计算策略，对算路拓扑模型进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑。

3、通过算法库保存算法服务系统内的基础算法，基于所述最简算路拓扑模型，通过所述基础算法进行路由计算；

4、在完成路由计算后，通过资源占用模块基于路由计算结果，进行网络资源数据库中相应资源的占用和修改；

5、通过消息回复模块向算法服务请求发起方返回路由计算结果；

6、通过日志记录模块记录每一个基础组件运行流程和结果；

7、通过标签分配模块为未分配资源的路由计算结果分配网络资源；

8、通过资源释放模块释放某条指定路由占用的资源。

在本发明实施中，端到端路由计算功能是算法服务平台最重要的功能，是多种子服务(包括但不限于：路由计算、BoD、OPVN等)的核心功能。网络日志等其他子服务，作为可测试性、可维护性的表现，也是重要的子服务，存在于算法服务平台内。所有的端到端算法服务，均可以看作是基于基础组件的不同逻辑调用方式，实现不同的子服务类型和计算策略。

图3是端到端路由计算过程各基础组件调用逻辑图。整个端到端的路径计算，步骤如下：

步骤一，由请求分析模块处理，分析请求的合法性，包括但不限于：原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持，业务场景是否支持。如果成功，将进行拓扑处理，失败将进入路由计算失败流程。

步骤二，拓扑处理模块基于业务层级化引擎和计算策略引擎解析的业务层级化信息和路由约束信息，对网络资源拓扑进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑，传递给后续基础组件。

步骤三，路径计算过程由算法库的基础组件承担，组件管理器通过选择算法库73中合适的子组件，基于前述网络资源拓扑，完成路径计算过程。如果成功，将标签分配，失败将进入路由计算失败流程。

步骤四，标签分配过程由标签分配模块完成，在路径计算结果的基础上，分配符合网络规则、计算策略的标签资源。该过程如果失败，将返回算法库的基础组件重新计算一条路径，成功，则进入下一流程。

步骤五，标签分配成功后，将依次资源占用模块和消息回复模块，完成相应的操作，并进入成功流程，完成整个端到端的计算服务。如果是失败流程，无论是从哪一个分支出来的失败，消息回复组件也将基于失败情况，回复相应的失败消息。

如图2所示，本发明实施例的上述处理可以参照以下处理步骤理解：

步骤101，算法服务平台通过接口代理模块接收到来自外部模块的算法服务请求，并转换成算法服务平台内的标准格式请求，转发给业务编排器。

步骤102，业务编排器收到算法服务请求后，找到子服务层对应的子服务，并发送给相应的子服务。

步骤103，子服务将请求转发给服务分发器，服务分发器基于相应的子服务和算法服务请求，调用引擎模块中相应的引擎

步骤104，在业务层级化引擎内对业务请求进行初步拆分，在业务层级化引擎内，根据业务场景、信息，选择对应的业务层级，如OCH、ODU、VC或者以太网等。在策略引擎将请求中包含的计算策略进行拆分，封装成标准数据结构，以服务文本形式存下，并发给相应的组件管理器。

步骤105，各组件管理器根据预设的服务逻辑(即决定调用哪些并如何调用各基础组件)，会预先调用各基础组件并进行封装好，等待引擎模块中调用模块根据计算策略和业务层级对相应组件管理器的调用。

步骤106，各组件管理器依自身逻辑，依次调用各基础组件，实现端到端的算法服务。其中，请求分析、资源数据库更新、消息回复等操作，均在基础组件内完成。

在本发明实施例中，部分网络使用者和管理者希望能够开放部分OTN网络开发权限，接入第三方独立开发的功能。因此，在本发明实施例中，同时提供部分开放的接口，支持第三方对OTN管控系统在可控制范围内进行有限扩展，因此，在本发明实施例中，所述方法进一步包括：

通过外部接口接入外部基础组件，实现与系统内部基础组件的替代与复用。

本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有信息传输的实现程序，所述程序被处理器92执行时实现如下方法步骤：

步骤801，转发模块接收算法服务请求，将所述算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将所述算法服务请求发给服务分发器；

具体包括如下处理：

步骤1，外部接口代理模作为整个系统的对外接口和系统边界，接收外部发送的算法服务请求，将所述算法服务请求转换为内部标准格式，转发给业务编排器；也就是说，外部接口代理模块接受外部的算法服务请求，可以屏蔽算法服务请求的来源以及差异性，生成系统内部通用的请求结构。算法服务请求具体包括：业务的基本服务类型、业务层级、业务等级、以及计算策略。

在本发明实施例中，外部用户可以自行选择服务类型，并搭配不同的业务层级和计算策略，实现需求的灵活、个性化组合的方式。

如图4所示，算法服务平台的用户，可根据自身需求，灵活选择需求，组成算法服务请求，具体步骤如下：

步骤一，选择一种服务类型，即业务的基本服务种类，包括但不限于：业务建立、业务恢复、BoD、OVPN、日志。大部分服务类型可以直接对应算法服务系统的子服务，个别的如，业务建立和业务恢复，都可以对应于路由计算子服务。

步骤二，选择一个业务层级。如果是算路相关的算法服务请求，需要选择一个业务层级，包括但不限于：OCH、ODU、VC、以太网、OAC等。

步骤三，选择业务等级，目前业界常用的业务等级包括：钻石级、金级、银级、铜级和铁级。不同的业务等级和业务层级相组合，会形成不同的保护和恢复方法和策略。

步骤四，选择计算策略。计算策略包括优先级、实现类型和资源类型三个属性。每一个策略由上述三个属性的组合而成。本步骤中，用户可以不选择，也可以选择一个或者多个计算策略进行组合。多个计算策略下，策略之间不能冲突，同时，应对每一个策略给出需要满足的优先级。在策略组合中，属性为必须的策略，优先级一定高于属性为尽量满足的策略。此外，用户在选择计算策略时，还能选择是否指定使用特定的算法等额外要求。

步骤五，对上述选择的服务类型、业务层级、业务等级和计算策略进行组合，形成一个完整的算法服务请求。

步骤2，业务编排器将所述算法服务请求发送到子服务层中相应的子服务；业务编排器需要根据算法服务请求，进行请求的分发和导引。

步骤3，相应的子服务将所述算法服务请求发给服务分发器；常见的子服务有端到端路径计算、按需分配带宽业务(Bandwidth on Demand，简称BoD)、光虚拟专用网络(Optical Virtual Private Network，简称OVPN)和网络日志，以及其他各种子服务。

步骤802，所述服务分发器基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器，通过各组件管理器封装的基础组件，基于模型适配器生成的算路拓扑模型实现端到端的算法服务。

步骤802具体包括如下处理：

步骤1，所述服务分发器基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；

步骤2，通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器；引擎模块提供了可用于算路服务的各种引擎中间件，其中包括但不仅限于：基于业务层次的业务层级化引擎，调度、处理基础算法组件完成复杂策略、约束等用户需求的策略引擎。引擎层是服务分发器的直接处理对象。步骤805具体包括如下处理：

业务层级化引擎响应于服务分发器的调用，选择与算法服务请求对应的业务层级；业务层级化引擎包含了不同层级的算法服务需求，目前SDN场景中常见的OCH、ODU、VC、以太网等业务均在其中。此外，随着后续需求的扩展，将会引入更加丰富的业务层次计算。

策略引擎响应于服务分发器的调用，将算法服务请求中的计算策略进行拆分封装；策略引擎包含了不同的路由计算策略(也称为路由计算约束)。路由计算约束可以从优先级、实现类型和资源类型三个角度进行描述。目前SDN场景中常见的路由计算约束按照优先级可以分为必须和尽量两种：必须满足的约束条件，要求路由结果必须无条件满足，否则失败；尽量的含义为在存在路由结果的前提下，优先选择符合约束条件的结果。路由计算约束按照实现类型可以分为经过(使用)和避开两类：经过的含义为使用相关的资源；避开的含义为不适用相关的资源。资源类型可以分为节点资源、链路资源、SRLG、SRNG、波长资源、中继板资源、光损伤约束等。算法服务的完整计算策略可以是上述策略的一种或者多种组合，例如，某请求可以包含必须经过某节点，又必须排除另一个节点，尽量经过某一条链路，并且尽量避开另一条链路。原则上，相关约束不能相互冲突，即不能存在某请求必须经过某一资源，同时必须或者尽量排除该资源。在本系统中，策略引擎仅做策略的拆分，校验工作由基础组件层中的请求分析完成。

调用模块根据计算策略和业务层级调用相应的组件管理器。也就是说，调用模块需要综合考虑计算策略和业务层级，从而调用合适的组件管理器。

步骤3，各组件管理器对针对端到端算法服务的各个基础组件进行适配、管理和扩展，根据预设的服务逻辑，调用各基础组件并进行封装；其中，预设的服务逻辑是根据经验设置的服务逻辑。

也就是说管理器层为了适配上层引擎层中，各个中间件差异化算路的需求，而对基础组件的适配、管理以及扩展，由于基础组件基本是业务无关、模型无关的，为了满足中间件中各项具体的业务需求，非常有必要对各项基本组件进行二次封装和扩展，这些工作将在管理器层完成。同时，该层还可以对外提供外部基础组件(可能来自具体运营商)接口及封装工作，提升基础组件的对外扩展性和灵活性。

步骤4，模型适配器屏蔽外部资源模型的差异，与外部的网络资源数据库通信，生成算法平台内部使用的算路拓扑模型；

步骤5，各基础组件接受所述组件管理器的调用，基于算路拓扑模型实现端到端的算法服务。具体包括如下处理：

1、通过请求分析模块对所述算法服务请求进行分析，校验相关原宿节点参数，对于存在路由约束冲突的算法服务请求，基于已有规则，对路由约束进行改造；具体地，通过请求分析模块对所述算法服务请求进行分析，校验原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持、以及业务场景是否支持，如果校验失败则将进入路由计算失败处理流程，如果校验成功则允许执行拓扑处理。

2、通过拓扑处理模块，基于已有的路由约束，对网络资源数据库的算路拓扑模型进行改造，保留必要的资源信息，形成最简算路拓扑模型；具体地，通过拓扑处理模块基于业务层级化引擎和策略引擎解析的业务层级和计算策略，对算路拓扑模型进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑。

3、通过算法库保存算法服务系统内的基础算法，基于所述最简算路拓扑模型，通过所述基础算法进行路由计算；

4、在完成路由计算后，通过资源占用模块基于路由计算结果，进行网络资源数据库中相应资源的占用和修改；

5、通过消息回复模块向算法服务请求发起方返回路由计算结果；

6、通过日志记录模块记录每一个基础组件运行流程和结果；

7、通过标签分配模块为未分配资源的路由计算结果分配网络资源；

8、通过资源释放模块释放某条指定路由占用的资源。

在本发明实施中，端到端路由计算功能是算法服务平台最重要的功能，是多种子服务(包括但不限于：路由计算、BoD、OPVN等)的核心功能。网络日志等其他子服务，作为可测试性、可维护性的表现，也是重要的子服务，存在于算法服务平台内。所有的端到端算法服务，均可以看作是基于基础组件的不同逻辑调用方式，实现不同的子服务类型和计算策略。

图3是端到端路由计算过程各基础组件调用逻辑图。整个端到端的路径计算，步骤如下：

步骤一，由请求分析模块处理，分析请求的合法性，包括但不限于：原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持，业务场景是否支持。如果成功，将进行拓扑处理，失败将进入路由计算失败流程。

步骤二，拓扑处理模块基于业务层级化引擎和计算策略引擎解析的业务层级化信息和路由约束信息，对网络资源拓扑进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑，传递给后续基础组件。

步骤三，路径计算过程由算法库的基础组件承担，组件管理器通过选择算法库73中合适的子组件，基于前述网络资源拓扑，完成路径计算过程。如果成功，将标签分配，失败将进入路由计算失败流程。

步骤四，标签分配过程由标签分配模块完成，在路径计算结果的基础上，分配符合网络规则、计算策略的标签资源。该过程如果失败，将返回算法库的基础组件重新计算一条路径，成功，则进入下一流程。

步骤五，标签分配成功后，将依次资源占用模块和消息回复模块，完成相应的操作，并进入成功流程，完成整个端到端的计算服务。如果是失败流程，无论是从哪一个分支出来的失败，消息回复组件也将基于失败情况，回复相应的失败消息。

如图2所示，本发明实施例的上述处理可以参照以下处理步骤理解：

步骤101，算法服务平台通过接口代理模块接收到来自外部模块的算法服务请求，并转换成算法服务平台内的标准格式请求，转发给业务编排器。

步骤102，业务编排器收到算法服务请求后，找到子服务层对应的子服务，并发送给相应的子服务。

步骤103，子服务将请求转发给服务分发器，服务分发器基于相应的子服务和算法服务请求，调用引擎模块中相应的引擎

步骤104，在业务层级化引擎内对业务请求进行初步拆分，在业务层级化引擎内，根据业务场景、信息，选择对应的业务层级，如OCH、ODU、VC或者以太网等。在策略引擎将请求中包含的计算策略进行拆分，封装成标准数据结构，以服务文本形式存下，并发给相应的组件管理器。

步骤105，各组件管理器根据预设的服务逻辑(即决定调用哪些并如何调用各基础组件)，会预先调用各基础组件并进行封装好，等待引擎模块中调用模块根据计算策略和业务层级对相应组件管理器的调用。

步骤106，各组件管理器依自身逻辑，依次调用各基础组件，实现端到端的算法服务。其中，请求分析、资源数据库更新、消息回复等操作，均在基础组件内完成。

在本发明实施例中，部分网络使用者和管理者希望能够开放部分OTN网络开发权限，接入第三方独立开发的功能。因此，在本发明实施例中，同时提供部分开放的接口，支持第三方对OTN管控系统在可控制范围内进行有限扩展，因此，在本发明实施例中，所述方法进一步包括：

通过外部接口接入外部基础组件，实现与系统内部基础组件的替代与复用。

本实施例所述计算机可读存储介质包括但不限于为：ROM、RAM、磁盘或光盘等。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种面向光传送网的算法服务系统，其特征在于，包括：

转发模块，用于接收算法服务请求，将所述算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将所述算法服务请求发给服务分发器；

所述服务分发器，用于基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；

引擎模块，用于提供针对端到端算法服务的各种引擎，通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器；

各个组件管理器，用于对针对端到端算法服务的各个基础组件进行适配、管理和扩展，根据预设的服务逻辑，调用各基础组件并进行封装；

基础组件层，用于保存针对端到端算法计算的各基础组件，接受所述组件管理器的调用，基于算路拓扑模型实现端到端的算法服务；

模型适配器，用于屏蔽外部资源模型的差异，与外部的网络资源数据库通信，生成算法服务系统内部使用的算路拓扑模型。

2.如权利要求1所述的系统，其特征在于，所述转发模块具体包括：

外部接口代理模块，用于接收算法服务请求，将所述算法服务请求转换为内部标准格式，转发给业务编排器；

业务编排器，用于将所述算法服务请求发送到子服务层中相应的子服务；

子服务层，用于保存针对端到端算法服务需求的子服务，相应的子服务将所述算法服务请求发给服务分发器。

3.如权利要求1所述的系统，其特征在于，所述系统进一步包括：

外部接口，用于接入外部基础组件，实现与系统内部基础组件的替代与复用。

4.如权利要求1所述的系统，其特征在于，所述引擎模块具体包括：

业务层级化引擎，用于响应于所述服务分发器的调用，选择与所述算法服务请求对应的业务层级；

策略引擎，用于响应于所述服务分发器的调用，将所述算法服务请求中的计算策略进行拆分封装；

调用模块，用于根据所述计算策略和所述业务层级调用相应的组件管理器。

5.如权利要求1所述的系统，其特征在于，所述基础组件层的基础组件具体包括：

请求分析模块，用于对所述算法服务请求进行分析，校验相关原宿节点参数，对于存在路由约束冲突的算法服务请求，基于已有规则，对路由约束进行改造；

拓扑处理模块，用于基于已有的路由约束，对网络资源数据库的算路拓扑模型进行改造，保留必要的资源信息，形成最简算路拓扑模型；

算法库，用于保存算法服务系统内的基础算法，基于所述最简算路拓扑模型，通过所述基础算法进行路由计算；

资源占用模块，用于在完成路由计算后，基于路由计算结果，进行网络资源数据库中相应资源的占用和修改；

消息回复模块，用于向算法服务请求发起方返回路由计算结果；

日志记录模块，用于记录每一个基础组件运行流程和结果；

标签分配模块，用于为未分配资源的路由计算结果分配网络资源；

资源释放模块，用于释放某条指定路由占用的资源。

6.如权利要求5所述的系统，其特征在于，所述请求分析模块具体用于：

对所述算法服务请求进行分析，校验原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持、以及业务场景是否支持，如果校验失败则将进入路由计算失败处理流程，如果校验成功则允许执行拓扑处理。

7.如权利要求1所述的系统，其特征在于，所述拓扑处理模块具体用于：

基于业务层级化引擎和策略引擎解析的业务层级和计算策略，对算路拓扑模型进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑。

8.如权利要求1所述的系统，其特征在于，所述算法服务请求具体包括：

业务的基本服务类型、业务层级、业务等级、以及计算策略。

9.一种面向光传送网的算法服务方法，其特征在于，基于上述权利要求1至8中任一项所述的面向光传送网的算法服务系统，所述方法具体包括：

转发模块接收算法服务请求，将所述算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将所述算法服务请求发给服务分发器；

所述服务分发器基于相应的子服务和所述算法服务请求，调用引擎模块中相应的引擎；通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器，通过各组件管理器封装的基础组件，基于模型适配器生成的算路拓扑模型实现端到端的算法服务。

10.如权利要求9所述的方法，其特征在于，转发模块接收算法服务请求，将所述算法服务请求转换为内部标准格式，并发送到相应的子服务，通过相应的子服务将所述算法服务请求发给服务分发器具体包括：

外部接口代理模块接收外部发送的算法服务请求，将所述算法服务请求转换为内部标准格式，转发给业务编排器；

业务编排器将所述算法服务请求发送到子服务层中相应的子服务；

相应的子服务将所述算法服务请求发给服务分发器。

11.如权利要求9所述的方法，其特征在于，所述方法进一步包括：

通过外部接口接入外部基础组件，实现与系统内部基础组件的替代与复用。

12.如权利要求9所述的方法，其特征在于，通过引擎选择与所述算法服务请求对应的业务层级，并将所述算法服务请求中的计算策略进行拆分封装，根据所述计算策略和所述业务层级调用相应的组件管理器具体包括：

通过业务层级化引擎响应所述服务分发器的调用，选择与所述算法服务请求对应的业务层级；

通过策略引擎响应所述服务分发器的调用，将所述算法服务请求中的计算策略进行拆分封装；

通过调用模块根据所述计算策略和所述业务层级调用相应的组件管理器。

13.如权利要求9所述的方法，其特征在于，通过各组件管理器封装的基础组件，基于模型适配器生成的算路拓扑模型实现端到端的算法服务具体包括：

通过请求分析模块对所述算法服务请求进行分析，校验相关原宿节点参数，对于存在路由约束冲突的算法服务请求，基于已有规则，对路由约束进行改造；

通过拓扑处理模块，基于已有的路由约束，对所述算路拓扑模型进行改造，保留必要的资源信息，形成最简算路拓扑模型；

通过算法库保存算法服务系统内的基础算法，基于所述最简算路拓扑模型，通过所述基础算法进行路由计算；

在完成路由计算后，通过资源占用模块基于路由计算结果，进行网络资源数据库中相应资源的占用和修改；

通过消息回复模块向算法服务请求发起方返回路由计算结果；

通过日志记录模块记录每一个基础组件运行流程和结果；

通过标签分配模块为未分配资源的路由计算结果分配网络资源；

通过资源释放模块释放某条指定路由占用的资源。

14.如权利要求13所述的方法，其特征在于，通过请求分析模块对所述算法服务请求进行分析，校验相关原宿节点参数，对于存在路由约束冲突的算法服务请求，基于已有规则，对路由约束进行改造具体包括：

通过请求分析模块对所述算法服务请求进行分析，校验原宿节点信息是否缺失及合法、约束条件是否冲突、业务层级是否支持、以及业务场景是否支持，如果校验失败则将进入路由计算失败处理流程，如果校验成功则允许执行拓扑处理。

15.如权利要求12所述的方法，其特征在于，通过拓扑处理模块，基于已有的路由约束，对算路拓扑模型进行改造，保留必要的资源信息，形成最简算路拓扑模型具体包括：

通过拓扑处理模块基于业务层级化引擎和策略引擎解析的业务层级和计算策略，对算路拓扑模型进行剪裁，去除不必要的资源，合并重复可替代的资源，形成简化的网络资源拓扑。

16.如权利要求9所述的系统，其特征在于，所述算法服务请求具体包括：

业务的基本服务类型、业务层级、业务等级、以及计算策略。

17.一种面向光传送网的算法服务设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求9至16中任一项所述的面向光传送网的算法服务方法的步骤。

18.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有信息传递的实现程序，所述程序被处理器执行时实现如权利要求9至16中任一项所述的面向光传送网的算法服务方法的步骤。

Images