分段路由策略下发方法、装置、设备、介质及程序产品与流程

本申请涉及数据处理技术领域，尤其涉及一种分段路由策略下发的方法、一种分段路由策略下发的装置、一种电子设备、一种计算机可读存储介质以及一种计算机程序产品。

背景技术

传统IP网络流量转发时，流量转发到节点时，在该节点上查询IP路由表才能确定下一跳设备。用户规划网络时，需要在网络各个节点增加配置来引导流量。分段路由(Segment Routing，简称SR)技术提出之后，赋予了用户直接定制流量完整转发路径的能力。

在SR技术应用于互联网协议(internet protocol，IP)转发中时，控制器可以收集网络拓扑之后，计算端到端的SR POLICY(分段路由策略)，并通过边界协议网关(bordergateway protocol，BGP)SR POLICY地址族向路径的头节点下发SR POLICY路由，头节点生成SR POLICY隧道。

在相关技术中，SR POLICY的下发包括如下三种方案：

1、基于PCEP协议的下发方案。PCEP协议起源于光传输网络，后来扩展用于RSVP-TE/SR-TE隧道、SR policy的下发，优点是协议较为清晰简单。但由于其并非原生的IP网络使用的技术，一般IP网络维护人员并不熟悉，IP网络设备(尤其是交换机)支持不够广泛，协议的开源实现也较少。

2、基于Netconf协议的下发方案。Netconf是网络设备的配置下发协议，可以通过下发静态配置方式实现SR Policy。优点是静态配置到设备上后，可完全脱离控制器运行。但缺点是下发效率极低，极端情况下会影响整个控制器的对网络拓扑的掌控。比如在网络比较恶劣环境下，控制器不能及时更新故障的Policy，从而导致骨干网流量转发有丢包的风险。

3、基于BGP-SR协议的下发方案。BGP-SR是BGP的一个扩展。由于BGP必然就是骨干网络的主要控制面协议，因此用BGP扩展来下发SR Policy是一种很好的方式。各大硬件厂家对BGP-SR的支持度也很好。但由于BGP-SR本质上是BGP路由，当控制器(BGP)故障后，如果不依赖GR(Grateful Restart)等特性，设备的SR Policy会丢失。

技术实现要素：

本申请提供一种分段路由策略下发方法、装置、设备、介质及程序产品，以解决现有技术中的分段路由策略下发时比较难兼顾下发效率和控制器故障引起的丢包问题。

第一方面，本申请实施例提供了一种分段路由策略下发的方法，所述方法应用于骨干网控制器中，所述方法包括：

获取待下发的分段路由策略信息，所述分段路由策略信息包括一个或多个候选路径信息，各所述候选路径信息包括托管属性；

根据所述托管属性，识别出托管候选路径信息以及非托管候选路径信息，其中，所述托管候选路径信息受所述骨干网控制器的调度，所述非托管候选路径信息不受所述骨干网控制器的调度；

采用路由协议将所述托管候选路径信息下发至路由设备中；

采用网管协议将所述非托管候选路径信息下发至路由设备中。

第二方面，本申请实施例还提供了一种分段路由策略下发的装置，所述装置应用于骨干网控制器中，所述装置包括：

分段路由策略信息获取模块，用于获取待下发的分段路由策略信息，所述分段路由策略信息包括一个或多个候选路径信息，各所述候选路径信息包括托管属性；

路径识别模块，用于根据所述托管属性，识别出托管候选路径信息以及非托管候选路径信息，其中，所述托管候选路径信息受所述骨干网控制器的调度，所述非托管候选路径信息不受所述骨干网控制器的调度；

托管候选路径信息下发模块，用于采用路由协议将所述托管候选路径信息下发至路由设备中；

非托管候选路径信息下发模块，用于采用网管协议将所述非托管候选路径信息下发至路由设备中。

第三方面，本申请实施例还提供了一种电子设备，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述第一方面的方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述第一方面的方法。

第五方面，本申请实施例还提供了一种计算机程序产品，所述计算机程序产品包括计算机可执行指令，所述计算机可执行指令在被执行时用于实现上述第一方面的方法。

本申请所提供的技术方案，具有如下有益效果：

在本实施例中，针对待下发的分段路由策略信息，骨干网控制器可以根据该分段路由策略信息中包含的一个或多个候选路径信息所携带的托管属性，识别出受骨干网控制器调度的托管候选路径信息以及不受骨干网控制器调度的非托管候选路径信息。对于托管候选路径信息采用路由协议下发，而对于非托管候选路径信息采用网管协议下发。通过路由协议与网管协议结合的方式，实现对分段路由策略的下发。通过采用路由协议较快地将托管候选路径信息下发至路由设备中，解决纯网管协议下发分段路由策略时引起的效率低的问题，保证了控制器的快速响应。通过采用网管协议下发永久保存在路由设备上的非托管候选路径信息，实现了在骨干网控制器长期崩溃等极端情况下，保持骨干网络的正常转发。达到了同时兼顾高可用性和下发效率的效果，而且对各大硬件厂家的路由设备有很好的兼容性。

附图说明

图1是本申请实施例一提供的一种分段路由策略下发的方法实施例的流程图；

图2是本申请实施例一提供的示例性场景中的SR Policy结构示意图；

图3是本申请实施例一提供的示例性场景中的网络架构示意图；

图4是本申请实施例一提供的示例性场景中的下发SR Policy的时序图；

图5是本申请实施例一提供的示例性场景中的新建SR Policy页面示意图；

图6是本申请实施例二提供的一种分段路由策略下发的装置实施例的结构框图；

图7是本申请实施例三提供的一种电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。

实施例一

图1为本申请实施例一提供的一种分段路由策略下发的方法实施例的流程图，本实施例可以应用于骨干网控制器中。

骨干网(Backbone Network)是用来连接多个区域或地区的高速网络。每个骨干网中至少有一个和其他骨干网进行互联互通的连接点。不同的网络供应商都可以拥有自己的骨干网，用以连接其位于不同区域的网络。

骨干网中可以包括智能控制器(即本实施例中的骨干网控制器)，其作用是对全网转发PE(Provider Edge，网络侧边缘设备)、CPE(Customer Provider Edge，客户侧边缘设备，主要用于接入本地专线客户)、VCPE(Virtual Customer Provider Edge，虚拟边缘设备，通过Internet或者4G/5G网络接入用户分支机构的VCPE设备，提供用户混合组网能力)等设备进行统一的资源管理、信息收集、配置下发、监控告警以及路径计算规划，实现全网资源的统一调度和管理。

本实施例可以采用骨干网控制器进行分段路由策略(Segment Routing Policy，简称SR Policy)的下发。其中，SR Policy提供了灵活的转发路径选择方法，满足用户不同的转发需求。当Segment Routing网络的源节点和目的节点之间存在多条路径时，合理利用SR Policy选择转发路径，不仅可以方便管理员对网络进行管理和规划，还可以有效地减轻网络设备的转发压力。

如图1所示，本实施例可以包括如下步骤：

步骤110，获取待下发的分段路由策略信息，所述分段路由策略信息包括一个或多个候选路径信息，各所述候选路径信息包括托管属性。

其中，分段路由策略信息是指SR Policy中包含的信息。示例性地，分段路由策略信息可以包括但不限于头部信息以及一个或多个候选路径(Candidate Path)信息。

头部信息示例性地可以包括SR Policy的标识信息，该标识信息可以采用headpoint(源节点)、color(路径颜色)、endpoint(目的节点，可由IP地址标识)这三种标识。

一个分段路由策略信息中可以包括一条或多条候选路径信息Candidate Path，每条候选路径信息示例性地可以包括托管属性、优先级属性、以及一个或多个段列表(Segment List)信息等。每个Segment List信息可以携带名称、权重、报文转发路径等信息。

托管属性用于指示当前候选路径信息是否受骨干网控制器的调度。

优先级属性用于指示当前候选路径信息的优先级，优先级高的优选路径会被优先下发。

步骤120，根据所述托管属性，识别出托管候选路径信息以及非托管候选路径信息。

在该步骤中，根据各候选路径信息中包含的托管属性的属性值，骨干网控制器可以将分段路由策略信息中包含的候选路径信息，分离出托管候选路径信息以及非托管候选路径信息。

其中，托管候选路径信息受骨干网控制器的调度；非托管候选路径信息不受骨干网控制器的调度。

在一种实施例中，托管候选路径信息包括至少两条，根据优先级属性，可以将优先级高的托管候选路径信息设定为主用路径信息，将优先级次高的托管候选路径信息设置为备用路径信息。策略上可以设置一主一备或者一主多备，目的是当优先级高的主用路径故障的时候，次优先级的备用路径会立马接管故障的主用路径的流量转发，这种Candidate Path之间的切换时间很短，基本可以做到不丢包，而且故障的Candidate Path会立马得到控制器的调度重新规划新的正常路径并立即下发从而得到恢复。

非托管候选路径信息的优先级可以设置为比托管候选路径信息的优先级低，这是一个保底的Candidate Path，不受控制器的调度，这样即使控制器故障或长期离线，路由设备还可以根据非托管候选路径信息指导流量转发工作，达到了高可用的目的。

在一种实施例中，所述托管属性的属性值包括BGP协议以及Netconf协议；所述步骤120进一步可以包括如下步骤：

若所述候选路径信息的托管属性的属性值为BGP协议，则将该候选路径信息确定为托管候选路径信息；若所述候选路径信息的托管属性的属性值为Netconf协议，则将该候选路径信息确定为非托管候选路径信息。

在实现时，各候选路径信息的托管属性的属性值可以由用户设定，如果该属性值为BGP协议，则表示当前候选路径信息为托管候选路径信息；如果该属性值为Netconf协议，则表示当前候选路径信息为非托管候选路径信息。

步骤130，采用路由协议将所述托管候选路径信息下发至路由设备中。

在该步骤中，对于托管候选路径信息，可以采用路由协议(Routing protocol)下发。路由协议是一种指定数据包转送方式的网上协议，路由协议与路由器协同工作，执行路由选择和数据包转发功能。

示例性地，路由协议可以包括BGP协议(Border Gateway Protocol，边界网关协议)，BGP是互联网上一个核心的去中心化自治路由协议，是一种用于自治系统AS(Autonomous System)之间的动态路由协议。进一步地，该BGP协议示例性可以包括BGP-SR协议，BGP-SR是BGP的一种扩展，可以用于通过BGP协议传递SR路由，让设备根据SR路由创建用于转发数据的SR Policy。

由于BGP是骨干网络的主要控制面协议，因此用BGP-SR协议来下发SR Policy是一种很好的方式，各大硬件厂家对BGP-SR的支持度也很好。

步骤140，采用网管协议将所述非托管候选路径信息下发至路由设备中。

在该步骤中，对于非托管候选路径信息，可以采用网管协议下发。网管协议又可以称为网络管理协议(Network Management Protocol)，它定义了网络管理者与网管代理间的通信方法。示例性地，网管协议可以包括Netconf(网络配置)协议，其中，Netconf是基于可扩展标记语言XML(Extensible Markup Language)的网络配置和管理协议，使用简单的基于RPC(Remote Procedure Call，远程过程调用)机制实现客户端和服务器之间通信。Netconf提供了一套管理网络设备的机制，用户可以使用这套机制增加、修改、或删除网络设备的配置，获取网络设备的配置和状态信息。通过Netconf协议，网络设备可以提供规范的应用程序编程接口API，应用程序可以直接使用这些API，向网络设备发送和获取配置。

当通过Netconf协议将非托管候选路径信息下发至路由设备中以后，则该非托管候选路径信息可脱离控制器的调度。

在本实施例中，针对待下发的分段路由策略信息，骨干网控制器可以根据该分段路由策略信息中包含的一个或多个候选路径信息所携带的托管属性，识别出受骨干网控制器调度的托管候选路径信息以及不受骨干网控制器调度的非托管候选路径信息。对于托管候选路径信息采用路由协议下发，而对于非托管候选路径信息采用网管协议下发。通过路由协议与网管协议结合的方式，实现对分段路由策略的下发。通过采用路由协议较快地将托管候选路径信息下发至路由设备中，解决纯网管协议下发分段路由策略时引起的效率低的问题，保证了控制器的快速响应。通过采用网管协议下发永久保存在路由设备上的非托管候选路径信息，实现了在骨干网控制器长期崩溃等极端情况下，保持骨干网络的正常转发。达到了同时兼顾高可用性和下发效率的效果，而且对各大硬件厂家的路由设备有很好的兼容性。

在一种实施例中，所述分段路由策略信息还可以包括头部信息；则在步骤130之前，本实施例还可以包括如下步骤：

采用所述网管协议将所述头部信息以及预设的故障检测机制下发至所述路由设备中。

其中，预设的故障检测机制用于进行链路的故障检测。本领域技术人员可以根据实际需求确定合适的故障检测机制，本实施例对此不作限制。例如，该故障检测机制可以包括BFD(Bidirectional Forwarding Detection，双向转发检测)或SBFD(Seamless Bidirectional Forwarding Detection，无缝双向转发检测)机制。BFD技术提供了一个通用的标准化的与介质和协议无关的快速故障检测机制，用于快速检测通信链路的故障。BFD检测机制是两个节点建立BFD会话，并通过BFD报文中携带的参数进行会话协商。BFD会话协商采用三次握手机制，协商成功后，以协商的报文收发时间在彼此的路径上周期性发送BFD报文。SBFD简化了BFD的会话协商机制。SBFD分为发起端和反射端，发起端作为检测端，向反射端发送SBFD报文触发会话协商，反射端仅环回发起端发送的SBFD报文，因此缩短了SBFD会话的协商时间，为网络节点路径检测带来灵活性，能够支撑SR隧道检测。

示例性地，该网管协议可以包括Netconf协议。

本实施例在下发候选路径信息以前，首先可以通过网管协议将分段路由策略信息的头部信息以及故障检测机制下发至路由设备中。这样路由设备在进行路径切换前，就可以先基于故障检测机制进行备用路径的故障检测，从而避免主用路径故障时，接管的备用路径是故障路径导致的丢包风险。

在一种实施例中，还可以包括如下步骤：

判断所述分段路由策略信息是否下发失败；若是，则执行回滚操作以删除所述分段路由策略信息的在先已下发数据，以及，发出下发失败通知；若否，则发出下发成功通知。

在一种实施例中，上述判断分段路由策略信息是否下发失败的步骤，进一步可以包括如下步骤：

当满足如下条件中的一个时，则判定所述分段路由策略信息下发失败；当均不满足如下条件时，则判定所述分段路由策略信息下发成功：所述头部信息以及所述故障检测机制下发失败；所述托管候选路径信息下发失败；所述非托管候选路径信息下发失败。

在该实施例中，若头部信息、故障检测机制、托管候选路径信息以及非托管候选路径信息的任一项下发失败，则可以判定当前分段路由策略信息下发失败。若头部信息、故障检测机制、托管候选路径信息以及非托管候选路径信息均成功下发，则可以判定当前分段路由策略信息下发成功。

具体的，在下发头部信息以及预设的故障检测机制后，若该头部信息以及故障检测机制下发失败，则判定当前分段路由策略信息下发失败，此时可以向管理员发出下发失败通知。若该头部信息以及故障检测机制下发成功，则按照优先级由高到低下发托管候选路径信息，一个托管候选路径信息下发成功后继续下发下一优先级的托管候选路径信息，直到所有托管候选路径信息都下发完毕。如果某个托管候选路径信息下发失败，则判定当前分段路由策略信息下发失败，并执行回滚操作，删除当前分段路由策略信息中在先已经下发的头部信息、故障检测机制以及托管候选路径信息，然后向管理员发出下发失败通知。当所有托管候选路径信息都下发成功，则开始下发非托管候选路径信息，如果非托管候选路径信息下发成功，则意味着当前分段路由策略信息下发成功，此时可以向管理员发出下发成功通知。如果非托管候选路径信息下发失败，则意味着当前分段路由策略信息下发失败，则需要回滚之前下发的所有数据，即删除当前分段路由策略信息中在先已经下发的头部信息、故障检测机制以及托管候选路径信息。

在一种实施例中，可以采用如下方式判断，所述头部信息以及所述故障检测机制下发失败，或者，所述托管候选路径信息下发失败，或者，所述非托管候选路径信息下发失败：

当发出所述头部信息以及所述故障检测机制，或者，所述托管候选路径信息，或者，所述非托管候选路径信息以后，接收到所述路由设备返回的响应失败消息。

在该实施例中，在向路由设备下发信息(包括：头部信息以及故障检测机制，或者，托管候选路径信息，或者，非托管候选路径信息)后，路由设备会返回响应消息(即下文的下发响应消息)，该响应消息包括响应失败消息或响应成功消息，如果控制器收到的是响应失败消息，则判定当前下发的信息没有被路由设备成功接收，此时可以判定该当前下发的信息下发失败。

在另一种实施例中，还可以采用如下方式判断，所述头部信息以及所述故障检测机制下发失败，或者，所述托管候选路径信息下发失败，或者，所述非托管候选路径信息下发失败：

当发出所述头部信息以及所述故障检测机制，或者，所述托管候选路径信息，或者，所述非托管候选路径信息以后，在设定的时长内没有接收到所述路由设备返回的响应消息。

具体的，由于整个分段路由策略信息的交互次数比较多，很容易因为网络问题导致下发信息后没有收到路由设备的响应消息的情况出现。对此，本实施例在控制器端侧会对分段路由策略信息做一个超时设定，如果在设定的时长内没有收到路由设备的响应，则会认为当前分段路由策略信息的下发失败。

本实施例在每次下发信息时，都会及时检测当前的下发信息是否下发成功，如果下发成功则继续下一个信息的下发，直到所有信息都下发完毕，则整个分段路由策略信息处理完成。如果某个信息下发失败，则判定当前分段路由策略信息下发失败，则可以回滚之前下发的信息，废弃当前分段路由策略信息，并通知管理员。可以及时并有效地检测出SR Policy下发失败的情况，避免出现丢包的情况出现。

在一种实施例中，托管候选路径信息包括至少两条，候选路径信息还可以包括优先级属性；步骤130进一步可以包括如下步骤：

将所述托管候选路径信息按照所述优先级属性进行排序；按照优先级由高到低的次序依次将所述托管候选路径信息下发至BGP服务器中，以由所述BGP服务器将所述托管候选路径信息发送至所述路由设备中。

在该实施例中，当托管候选路径信息的数量超过一条时，在下发托管候选路径信息时，会优先下发优先级最高的托管候选路径信息，在该优先级最高的托管候选路径信息下发成功后，接着下发优先级次高的托管候选路径信息，以此类推，直到所有托管候选路径信息都下发完成。这么做的目的是如果低优先级的托管候选路径信息先下发，会导致SR Policy在下发的过程中，路由设备从次优先级的托管候选路径信息对应的路径切换到高优先级的托管候选路径信息对应的路径，从而发生不必要切换。

在该实施例中，通过路由协议将托管候选路径信息下发至路由设备中的实现过程，是通过BGP服务器完成的。骨干网控制器首先按照优先级由高到低的次序依次将托管候选路径信息下发至BGP服务器中，BGP服务器每接收到一个托管候选路径信息以后，则可以将该托管候选路径信息下发给路由设备。在这种情况下，控制器收到的路由设备返回的响应消息，也是经由BGP服务器转发的，即，路由设备向BGP服务器返回响应消息，BGP服务器再将该响应消息发送给控制器。

示例性地，该BGP服务器可以包括Gobgp服务器，Gobgp是开源软件，用于实现各种BGP以及扩展协议。

在一种实施例中，上述按照优先级由高到低的次序依次将所述托管候选路径信息下发至BGP服务器中，以由所述BGP服务器将所述托管候选路径信息发送至所述路由设备中的步骤，进一步可以包括如下步骤：

当将当前托管候选路径信息下发至BGP服务器以后，接收所述BGP服务器返回的下发响应消息；若根据所述下发响应消息判定该托管候选路径信息下发成功，则判断是否还有未下发的托管候选路径信息；若是，则选取下一优先级的托管候选路径信息下发至所述BGP服务器中；若否，则执行所述采用网管协议将所述非托管候选路径信息下发至路由设备中的步骤；若根据所述下发响应消息判定该托管候选路径信息下发失败，则判定当前分段路由策略信息下发失败。

在该实施例中，当前托管候选路径信息下发至BGP服务器以后，BGP服务器将托管候选路径信息下发至路由设备中，然后接收路由设备返回的下发响应消息，并将下发响应消息返回至控制器中。控制器对该下发响应消息进行分析，如果该下发响应消息为响应失败消息，则判定当前托管候选路径信息下发失败，此时可以认为当前分段路由策略信息下发失败。如果该下发响应消息为响应成功消息，则判定当前托管候选路径信息下发成功，此时可以查看是否还有未下发的托管候选路径信息，如果有未下发的托管候选路径信息，则选取下一优先级的托管候选路径信息下发至BGP服务器中。如果所有托管候选路径信息均下发完毕，则执行步骤140，开始非托管候选路径信息的下发。

在一种实施例中，步骤140进一步可以包括如下步骤：

将所述非托管候选路径信息下发至Netconf服务器中，以由所述Netconf服务器将所述非托管候选路径信息下发至所述路由设备中。

在该实施例中，通过网管协议将非托管候选路径信息下发至路由设备中的实现过程，是通过Netconf服务器完成的。骨干网控制器将非托管候选路径信息下发至Netconf服务器中，Netconf服务器接收到非托管候选路径信息以后，则可以将该非托管候选路径信息下发给路由设备。在这种情况下，控制器收到的路由设备返回的响应消息，也是经由Netconf服务器转发的，即，路由设备向Netconf服务器返回响应消息，Netconf服务器再将该响应消息发送给控制器。

在一种实施例中，各所述候选路径信息还包括一个或多个段列表信息，各所述段列表信息包括路径字段；步骤110进一步可以包括如下步骤：

接收运维管理平台发送的分段路由策略信息，其中，所述分段路由策略信息为所述运维管理平台在接收到用户经由交互界面输入的分段路由策略编辑信息以后，对所述分段路由策略编辑信息进行校验通过后生成的信息。根据各候选路径信息的各段列表信息进行算路处理，以确定各段列表信息的最优路径，并将所述最优路径填入对应段列表信息的路径字段中，得到待下发的分段路由策略信息。

在该实施例中，运维管理平台可以通过客户端向用户(如管理人员)展示交互界面，用户经由该交互界面可以输入分段路由策略编辑信息。客户端捕获到用户输入的分段路由策略编辑信息以后，对该分段路由策略编辑信息进行初步的校验(比如检查各候选路径信息是否存在冲突)，并在校验通过以后将该分段路由策略编辑信息生成分段路由策略信息发送至运维管理平台，运维管理平台对该分段路由策略信息进行更深层次的校验(比如SR Policy中各Candidate Path之间的约束关系是否合法等)，并在校验通过以后启动一个带taskID的任务，将分段路由策略信息重新封装在该任务中，并将该任务发往骨干网控制器。这样，骨干网控制器收到的分段路由策略信息是经过双重校验后的，将一部分校验工作放在运维管理平台中，可以降低骨干网控制器的校验工作量，提高任务下发效率。

控制器获得分段路由策略信息以后，则可以对其进行算路处理，以确定各段列表信息的最优路径，并将该最优路径填入对应段列表信息的路径字段中，得到待下发的分段路由策略信息。

在一种实施例中，在进行算路处理时，骨干网控制器可以首先采集组网拓扑中所有链路的链路参数，如链路开销、链路带宽、链路当前带宽、链路剩余带宽、延时、抖动以及丢包率等。然后根据获取到的链路参数以及组网拓扑，采用设定的路径选择算法进行算路处理，得到与当前段列表对应的多条备选路径。其中，路径选择算法示例性地可以包括CSPF(ConstrainedShortest Path First，约束最短路径优先)、OSPF(Open Shortest Path First，开放最短路径优先)等算法。最后按照一定的选择策略，从多条备选路径中选取最优路径。

在一种实施例中，上述根据各候选路径信息的各段列表信息进行算路处理，以确定各段列表信息的最优路径的步骤，进一步可以包括如下步骤：

将各候选路径信息的各段列表信息发送至调度系统中，以由所述调度系统采用预设的路径选择算法对所述段列表信息进行算路处理，得到各段列表信息的最优路径。

在该实施例中，可以通过调度系统进行算路。具体的，当控制器分离出托管候选路径信息以及非托管候选路径信息以后，则可以将该托管候选路径信息以及非托管候选路径信息中的各段列表信息发送给调度系统中，由调度系统进行算路，得到与各段列表信息对应的最优路径。本实施例对调度系统采用的路径选择算法不作限制。

其中，该调度系统可以设置于骨干网控制器中，也可以独立于骨干网控制器设置于骨干网中，本实施例对此不作限制。

为了使得本领域技术人员能够更好地理解本实施例，以下通过一个具体的应用场景示例对本实施例的SR Policy下发过程进行示例性说明。

在骨干网络实际的流量转发流程中，承载业务流量的转发单位是Policy(策略)，Policy的headpoint和endpoint分别指示了流量转发的源节点(也称为入节点)和目的节点。Policy可以配置多个Candidate Path，每个Candidate Path相当于一个备用转发子策略(即候选路径信息)，每个Candidate Path下面又可以有多个Segment list来做负载均衡。当优先级高的Candidate Path状态down时(意味着该条Candidate Path下所有Segment list都down了)，路由设备能自动为Policy做故障切换，切到优先级低且状态正常的Candidate Path上面。而且控制器检查down状态的Segment list，代表着该Segment list的路径已经故障，需要控制器重新为其规划一条新的路径。

在本示例中，SR Policy中设置了三个Candidate Path，如图2所示，三个Candidate Path包含两个托管Candidate Path和一个非托管Candidate Path。两个托管Candidate Path中，一个作为主Candidate Path，设置的优先级更高，一个作为备Candidate Path，设置的优先级稍低些。非托管Candidate Path设置的优先级最低。这里为一个SR Policy设计了两个托管Candidate Path，目的是当优先级高的托管Candidate Path故障的时候，设备上的次优先级的托管Candidate Path会立马接管故障的托管Candidate Path的流量转发，这种Candidate Path之间的切换时间很短，基本可以做到不丢包，而且故障的Candidate Path会立马得到控制器的调度重新规划新的正常路径并立即下发从而得到恢复。

在图2中，每个Candidate Path包含origin address(源地址，即源节点的地址信息)、origin proto(源协议，用于记录托管属性的属性值)、discriminator(鉴别器，用于区分不同的Candidate Path)、asn(用于描述对数据进行表示、编码、传输和解码的数据格式)、preference(用于描述优先级属性)、name(段列表名称)、weight(段列表权重)、path(段列表指示的转发路径)等字段，其中，name、weight、path属于Segment list的字段。通过preference的字段值可以得到Candidate Path的优先级，通过origin proto的字段值可以得到Candidate Path的是托管Candidate Path还是非托管Candidate Path。

如图2所示，SR Policy中除了包括Candidate Path的相关信息以外，还可以包括头部信息，该头部信息可以包括headpoint(源节点)、endpoint(目的节点)、color(颜色)三个字段，这三个字段用于唯一标识一个SR Policy。

在一种实施例中，如图3的网络架构示意图所示，骨干网控制器可以与运维管理平台(Operation Administrator Manager，简称OAM)、Gobgp服务器、NETCONF服务器、监控系统、Exabgp客户端、GRPC客户端、SNMP(简单网络管理协议)客户端、OSS存储集群、告警系统等交互。而OAM平台又提供客户端的交互界面(WebUI)向管理员提供编辑SR Policy的入口。在下发SR Policy的过程中，骨干网控制器通过Gobgp服务器、NETCONF服务器、Exabgp客户端、GRPC客户端、SNMP客户端等将SR Policy下发至路由设备中。如图3所示，路由设备可以包括不同厂商的路由器。

基于图2的Policy结构图以及图3的网络架构，图4示出了下发SR Policy的时序图，以下对图4的下发过程进行说明：

1.操作编辑Policy。管理员新建一条SR Policy，在该SR Policy中创建三个Candidate Path，每个Candidate Path各配置一个Segment list。托管Candidate Path有两个，一主一备，优先级高的为主，非托管的Candidate Path使用最低的优先级。

在一种实现中，当管理员点击WebUI界面中的新建SR Policy的按钮时，可以展示如图5所示的新建SR Policy页面示意图，管理员可以在该新建SR Policy页面中进行编辑，当编辑完成以后，点击“完成”按钮则可以将SR Policy的相关信息提交至WebUI中。

2.初步参数校验。WebUI界面会对提交的SR Policy各字段进行初步合法性校验，例如根据SR Policy中的origin address、origin proto、discriminator、asn四个字段判断是否存在冲突的Candidate Path。

3.提交请求。WebUI校验通过后，会基于SR Policy生成下发请求，并将下发请求发送至OAM服务器(OAM平台包括OAM服务器和OAM客户端)。

4.参数深入校验，管理请求任务。OAM服务器会对SR Policy做更深入的参数校验，比如SR Policy的Candidate Path之间的约束关系是否合法等。校验通过后，OAM服务器会启动一个带taskID的任务，将分段路由策略信息重新封装成下发任务。

5.提交Policy更新请求。OAM服务器生成下发任务以后，将下发任务发送至控制器中。

6.分离出托管Candidate Path和非托管Candidate Path。控制器接收到新的下发任务后，从中提取出SR Policy，并按照origin proto字段值，从SR Policy中分离出托管Candidate Path(origin proto字段值为BGP协议则该Candidate Path为托管Candidate Path)和非托管Candidate Path(origin proto字段值为Netconf协议则该Candidate Path为非托管Candidate Path)。

7.Candidate Path优先级排序。按照preference字段值，将所有Candidate Path按照优先级由高到低进行排序。

8.进入调度系统算路，分别计算出最优路径。控制器可以将各Candidate Path中Segment list放入调度系统做算路，规划出该Segment list的最优的流量转发路径，并将该最优路径填入Segment list的path字段中。

需要说明的是，本实施例中并不对步骤6-8的执行顺序作限定，在其他实现中，还可以先进行算路，然后按优先级排序最后再按照托管属性进行Candidate Path下发。

9.下发Policy头部信息，以及BFD。下发Candidate Path之前需要先下发Policy头部信息以及故障检测机制BFD。示例性地，BFD又进一步包括SBFD。如果不先下发SBFD，可能会出现当前Candidate Path故障时，下一条接管流量的Candidate Path也是故障的情形，导致丢包风险。而SBFD的下发又依赖于SR Policy的下发，因此在本步骤中通过网管协议将Policy头部信息以及SBFD一起下发给Netconf服务器(路由协议不支持SBFD的下发)。

10.编码yang请求，发送给设备。Netconf服务器将收到的Policy头部信息以及SBFD编码成yang请求(yang是一种数据建模语言，是专门为Netconf定制的一种模型配置语言)，并将该yang请求发送至路由设备中。

11-14.BFD下发到设备失败或者超时。如果Netconf服务器收到路由设备返回的下发失败响应消息，则会回复控制器BFD下发失败。控制器根据该BFD下发失败的消息，判定整个下发任务的失败，然后向OAM服务器回复失败消息，OAM服务器再通过WebUI界面将该下发失败消息通知给管理员。

11-14.BFD下发成功。如果Netconf服务器收到路由设备返回的下发成功响应消息，则会回复控制器BFD下发成功。然后控制器按优先级从高到低的次数，首先下发高优先级的托管Candidate Path，这里使用BGP-SR(Gobgp服务器)来实现，接着Gobgp服务器将该高优先级的托管Candidate Path下发给路由设备。

15-19.托管Candidate Path下发失败或者超时。如果Gobgp服务器收到路由设备返回的下发失败响应消息，则会回复控制器托管Candidate Path下发失败。控制器根据该托管Candidate Path下发失败的消息，需要对之前向Netconf服务器下发的SR Policy头部信息和SBFD进行回滚操作，即，向Netconf服务器发送回滚BFD的操作指令，以使得Netconf服务器删除已下发的SR Policy头部信息和SBFD，以此废弃当前下发任务。接着，控制器向OAM服务器回复下发任务失败的消息，OAM服务器再通过WebUI界面将该下发失败的消息通知给管理员。

15-18.托管Candidate Path下发成功。如果Gobgp服务器收到路由设备返回的下发成功响应消息，则会回复控制器托管Candidate Path下发成功。控制器根据该托管Candidate Path下发成功的消息，下发另一条次优先级的托管Candidate Path，该次优先级的托管Candidate Path的下发过程与第一条托管Candidate Path的下发流程相同。如果该次优先级的托管Candidate Path下发失败，额外操作是要多回滚上一条下发的托管Candidate Path。当下发成功所有托管Candidate Path之后，可以开始下发非托管Candidate Path，这里使用Netconf来实现下发，即，将非托管Candidate Path下发至非托管Netconf服务器，由Netconf服务器将该非托管Candidate Path编码成yang请求后发送至路由设备中。

19-24.非托管Candidate Path下发失败或者超时。如果Netconf服务器收到路由设备返回的下发失败响应消息，则会回复控制器该非托管Candidate Path下发失败。控制器根据该非托管Candidate Path下发失败的消息，需要回滚之前下发的所有托管Candidate Path、SBFD和SR Policy头部信息，即，向Netconf服务器发送回滚BFD的操作指令，以使得Netconf服务器删除已下发的SR Policy头部信息和SBFD，并向Gobgp服务器发送回滚托管Candidate Path的操作指令，以使得Gobgp服务器删除已下发的所有托管Candidate Path，以此废弃当前下发任务。接着，控制器向OAM服务器回复下发任务失败的消息，OAM服务器再通过WebUI界面将该下发失败的消息通知给管理员。

19-23.非托管Candidate Path下发成功。如果Netconf服务器收到路由设备返回的下发成功响应消息，则会回复控制器该非托管Candidate Path下发成功。控制器根据该非托管Candidate Path下发成功的消息，判定当前下发任务下发成功。则可以将当前SR Policy进行持久化处理，同时，控制器向OAM服务器回复下发任务成功的消息，OAM服务器再通过WebUI界面将该下发成功的消息通知给管理员。

本示例综合稳定性、协议成熟度、与骨干网络的配合度，将Candidate Path分为托管Candidate Path以及非托管Candidate Path，使用Netconf+BGP-SR的方式对SR Policy进行下发。

对于托管Candidate Path采用BGP-SR协议下发，目的是提高Candidate Path的下发效率，当托管Candidate Path发生故障时，控制器能够及时发现并能迅速的为其规划新的路径，并立刻下发更新托管Candidate Path，以避开故障的链路。

对于非托管Candidate Path采用Netconf协议进行异步下发，以使得非托管Candidate Path能够永久存储在设备中，这样一旦控制器长期离线，使得托管Candidate Path下发被撤销，这种情况下设备还可以根据Netconf下发的非托管Candidate Path指导流量转发工作，相当于有一个高可用的兜底策略，避免骨干网络流量转发的瘫痪。

通过上述方案，既能解决纯Netconf方案下发效率低的问题，保证控制器的快速响应和下发效率。也保证在骨干网控制器长期崩溃等极端情况下骨干网络的正常转发。而且对各大硬件厂家的网络设备有很好的兼容性。

实施例二

图6为本申请实施例二提供的一种分段路由策略下发的装置实施例的结构框图，所述装置应用于骨干网控制器中，可以包括如下模块：

分段路由策略信息获取模块610，用于获取待下发的分段路由策略信息，所述分段路由策略信息包括一个或多个候选路径信息，各所述候选路径信息包括托管属性；

路径识别模块620，用于根据所述托管属性，识别出托管候选路径信息以及非托管候选路径信息，其中，所述托管候选路径信息受所述骨干网控制器的调度，所述非托管候选路径信息不受所述骨干网控制器的调度；

托管候选路径信息下发模块630，用于采用路由协议将所述托管候选路径信息下发至路由设备中；

非托管候选路径信息下发模块640，用于采用网管协议将所述非托管候选路径信息下发至路由设备中。

在一种实施例中，所述分段路由策略信息还包括头部信息；所述装置还可以包括如下模块：

故障检测机制下发模块，用于在采用路由协议将所述托管候选路径信息下发至路由设备中之前，采用所述网管协议将所述头部信息以及预设的故障检测机制下发至所述路由设备中。

在一种实施例中，所述装置还可以包括如下模块：

下发结果判断模块，用于判断所述分段路由策略信息是否下发失败；若是，则执行失败处理模块；若否，则执行成功处理模块；

执行失败处理模块，用于执行回滚操作以删除所述分段路由策略信息的在先已下发数据，以及，发出下发失败通知；

执行成功处理模块，用于发出下发成功通知。

在一种实施例中，所述下发结果判断模块具体用于：

当满足如下条件中的一个时，则判定所述分段路由策略信息下发失败；当均不满足如下条件时，则判定所述分段路由策略信息下发成功：

所述头部信息以及所述故障检测机制下发失败；

所述托管候选路径信息下发失败；

所述非托管候选路径信息下发失败。

在一种实施例中，采用如下方式判断，所述头部信息以及所述故障检测机制下发失败，或者，所述托管候选路径信息下发失败，或者，所述非托管候选路径信息下发失败：

当发出所述头部信息以及所述故障检测机制，或者，所述托管候选路径信息，或者，所述非托管候选路径信息以后，接收到所述路由设备返回的响应失败消息；

或者，

当发出所述头部信息以及所述故障检测机制，或者，所述托管候选路径信息，或者，所述非托管候选路径信息以后，在设定的时长内没有接收到所述路由设备返回的响应消息。

在一种实施例中，所述托管候选路径信息包括至少两条，所述候选路径信息还包括优先级属性；

所述托管候选路径信息下发模块630可以包括如下子模块：

排序子模块，用于将所述托管候选路径信息按照所述优先级属性进行排序；

BGP下发子模块，用于按照优先级由高到低的次序依次将所述托管候选路径信息下发至BGP服务器中，以由所述BGP服务器将所述托管候选路径信息发送至所述路由设备中。

在一种实施例中，所述BGP下发子模块具体用于：

当将当前托管候选路径信息下发至BGP服务器以后，接收所述BGP服务器返回的下发响应消息；

若根据所述下发响应消息判定该托管候选路径信息下发成功，则判断是否还有未下发的托管候选路径信息；若是，则选取下一优先级的托管候选路径信息下发至所述BGP服务器中；若否，则执行所述采用网管协议将所述非托管候选路径信息下发至路由设备中的步骤；

若根据所述下发响应消息判定该托管候选路径信息下发失败，则判定当前分段路由策略信息下发失败。

在一种实施例中，所述非托管候选路径信息下发模块640具体用于：

将所述非托管候选路径信息下发至Netconf服务器中，以由所述Netconf服务器将所述非托管候选路径信息下发至所述路由设备中。

在一种实施例中，各所述候选路径信息还包括一个或多个段列表信息，各所述段列表信息包括路径字段；所述分段路由策略信息获取模块610可以包括如下子模块：

分段路由策略信息接收子模块，用于接收运维管理平台发送的分段路由策略信息，其中，所述分段路由策略信息为所述运维管理平台在接收到用户经由交互界面输入的分段路由策略编辑信息以后，对所述分段路由策略编辑信息进行校验通过后生成的信息；

算路处理子模块，用于根据各候选路径信息的各段列表信息进行算路处理，以确定各段列表信息的最优路径，并将所述最优路径填入对应段列表信息的路径字段中，得到待下发的分段路由策略信息。

在一种实施例中，所述算路处理子模块具体用于：

将各候选路径信息的各段列表信息发送至调度系统中，以由所述调度系统采用预设的路径选择算法对所述段列表信息进行算路处理，得到各段列表信息的最优路径。

在一种实施例中，所述托管属性的属性值包括BGP协议以及Netconf协议；

所述路径识别模块620具体用于：

若所述候选路径信息的托管属性的属性值为BGP协议，则将该候选路径信息确定为托管候选路径信息；

若所述候选路径信息的托管属性的属性值为Netconf协议，则将该候选路径信息确定为非托管候选路径信息。

本申请实施例所提供的一种分段路由策略下发的装置可执行本申请实施例一中的一种分段路由策略下发的方法，具备执行方法相应的功能模块和有益效果。

实施例三

图7为本申请实施例三提供的一种电子设备的结构示意图，如图7所示，该电子设备包括处理器710、存储器720、输入装置730和输出装置740；电子设备中处理器710的数量可以是一个或多个，图7中以一个处理器710为例；电子设备中的处理器710、存储器720、输入装置730和输出装置740可以通过总线或其他方式连接，图7中以通过总线连接为例。

存储器720作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请实施例中的上述实施例一对应的程序指令/模块。处理器710通过运行存储在存储器720中的软件程序、指令以及模块，从而执行电子设备的各种功能应用以及数据处理，即实现上述的方法实施例一中提到的方法。

存储器720可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器720可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器720可进一步包括相对于处理器710远程设置的存储器，这些远程存储器可以通过网络连接至设备/终端/服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置730可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。输出装置740可包括显示屏等显示设备。

实施例四

本申请实施例四还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行上述方法实施例一的方法。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本申请任意实施例所提供的方法中的相关操作。

实施例五

本申请实施例五还提供一种计算机程序产品，该计算机程序产品包括计算机可执行指令，所述计算机可执行指令在由计算机处理器执行时用于执行上述方法实施例一的方法。

当然，本申请实施例所提供的一种计算机程序产品，其计算机可执行指令不限于如上所述的方法操作，还可以执行本申请任意实施例所提供的方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本申请可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台电子设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

值得注意的是，上述装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。