CN112511437A

CN112511437A - 验证业务链的方法、发送节点、转发节点、业务功能节点

Info

Publication number: CN112511437A
Application number: CN202010322387.8A
Authority: CN
Inventors: 刘尧
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2020-04-22
Filing date: 2020-04-22
Publication date: 2021-03-16
Anticipated expiration: 2040-04-22
Also published as: EP4135275A4; CN112511437B; WO2021213082A1; US20230171183A1; EP4135275A1

Abstract

本公开实施例提供了一种验证业务链的方法，用于发送节点，所述方法包括：发送业务链验证请求信息；其中，所述业务链验证请求信息为段路由报文，其段列表至少包括待验证业务功能节点的段标识；所述业务链验证请求信息包括验证请求，所述验证请求用于要求业务链的业务节点对待验证业务功能节点进行验证以验证业务链，并向检查节点发送验证结果；所述业务节点包括业务功能节点和业务功能转发节点。

Description

验证业务链的方法、发送节点、转发节点、业务功能节点

技术领域

本公开实施例涉及业务链技术领域，特别涉及一种验证业务链的方法、发送节点、业务功能转发节点、业务功能节点。

背景技术

业务链(Service Function Chain，SFC)是一种给应用层提供有序服务的技术，其通过在报文中添加业务链路径信息来实现报文按照指定的路径依次经过业务功能设备，从而将网络设备上的业务功能(Service Function，SF)在逻辑层面上联接起来，形成有序的业务功能组合。例如，业务链的逻辑结构可参照图17。

为保证业务链部署的正确性，在业务链编排完成后需从数据平面对其进行验证，例如验证业务链上的各个业务功能是否按预期顺序编排、功能是否正常等。

但基于业务平面封装和转发平面封装分离实现的网络服务头(Network ServiceHeader，NSH)的业务链验证方式在很多方面并不适用。

发明内容

本公开实施例提供一种验证业务链的方法、发送节点、业务功能转发节点、业务功能节点。

第一方面，本公开实施例提供一种验证业务链的方法，用于发送节点，所述方法包括：

发送业务链验证请求信息；

其中，

所述业务链验证请求信息为段路由报文，其段列表至少包括待验证业务功能节点的段标识；所述业务链验证请求信息包括验证请求，所述验证请求用于要求业务链的业务节点对待验证业务功能节点进行验证以验证业务链，并向检查节点发送验证结果；所述业务节点包括业务功能节点和业务功能转发节点。

在一些实施例中，所述检查节点为发送节点；在所述发送业务链验证请求信息后，还包括：

接收所述验证结果；

根据所述验证结果，验证所述业务链。

在一些实施例中，所述待验证业务功能节点包括业务链的多个业务功能节点；

或者，

所述待验证业务功能节点为业务链的一个业务功能节点；

在一些实施例中，所述业务链验证请求信息还包括用于表明业务链验证请求信息的身份的身份信息，所述身份信息包括以下至少一项：

身份标识；

与待验证业务功能节点的段标识对应的身份段标识。

在一些实施例中，所述业务链验证请求信息为路径验证请求信息，所述验证请求用于要求验证待验证业务功能节点的位置和业务功能的类型。

在一些实施例中，所述待验证业务功能节点包括业务链的所有的业务功能节点。

在一些实施例中，所述待验证业务功能节点为业务链的一个业务功能节点；

在所述发送业务链验证请求信息后，还包括：

以所述业务链的下一个业务功能节点为待验证业务功能节点，并返回所述发送业务链验证请求信息的步骤。

在一些实施例中，所述业务链验证请求信息为功能验证请求信息，所述验证请求用于要求验证待验证业务功能节点的业务功能的正常性。

在一些实施例中，所述待验证业务功能节点为业务链的一个业务功能节点。

第二方面，本公开实施例提供一种验证业务链的方法，用于业务功能转发节点，所述方法包括：

接收发送节点发送的业务链验证请求信息；

根据所述业务链验证请求信息，对下属的待验证业务功能节点进行验证；

其中，

在一些实施例中，在所述对下属的待验证业务功能节点进行验证后，还包括：

向所述检查节点发送验证结果。

在一些实施例中，所述业务链验证请求信息为路径验证请求信息，所述验证请求用于要求验证待验证业务功能节点的位置和业务功能的类型；所述对下属的待验证业务功能节点进行验证包括：

根据所述业务链验证请求信息中的待验证业务功能节点，在本地预存的信息表中查询到下属的待验证业务功能节点的位置和业务功能的类型；

根据所述待验证业务功能节点的位置和业务功能的类型得到验证结果，并向所述检查节点发送验证结果。

在一些实施例中，所述对下属的待验证业务功能节点进行验证包括：

根据所述业务链验证请求信息中的待验证业务功能节点，向下属的待验证业务功能节点发送验证信息。

在一些实施例中，在所述向下属的待验证业务功能节点发送验证信息后，还包括：

接收所述待验证业务功能节点的验证反馈信息；

根据所述验证反馈信息得到验证结果，并向所述检查节点发送验证结果。

在一些实施例中，所述向下属的待验证业务功能节点发送验证信息包括：

将所述业务链验证请求信息作为验证信息转发给下属的待验证业务功能节点。

根据所述业务链验证请求信息产生验证信息，向下属的待验证业务功能节点发送验证信息。

第三方面，本公开实施例提供一种验证业务链的方法，用于业务功能节点，所述方法包括：

从上联的业务功能转发节点接收发送节点发送的业务链验证请求信息；

根据所述业务链验证请求信息进行验证，得到验证反馈信息；

其中，

在一些实施例中，在所述根据所述业务链验证请求信息进行验证，得到验证反馈信息后，还包括：

将所述验证反馈信息发送给上联的业务功能转发节点。

将所述验证反馈信息作为验证结果，发送给检查节点。

第四方面，本公开实施例提供一种发送节点，其包括：

第一发送模块，用于发送业务链验证请求信息；

其中，

在一些实施例中，所述发送节点还包括：

第一接收模块，用于接收所述验证结果；

至少一个处理器，配置为根据所述验证结果，验证所述业务链。

第五方面，本公开实施例提供一种业务功能转发节点，其包括：

第二接收模块，用于接收发送节点发送的业务链验证请求信息；

至少一个处理器，配置为根据所述业务链验证请求信息，对下属的待验证业务功能节点进行验证；

其中，

在一些实施例中，所述业务功能转发节点还包括：

第二发送模块，用于向所述检查节点发送验证结果。

在一些实施例中，所述业务功能转发节点还包括：

第三发送模块，用于根据所述业务链验证请求信息中的待验证业务功能节点，向下属的待验证业务功能节点发送验证信息。

在一些实施例中，所述业务功能转发节点还包括：

第三接收模块，用于接收所述待验证业务功能节点的验证反馈信息；

所述处理器还配置为根据所述验证反馈信息得到验证结果，并向所述检查节点发送验证结果。

第六方面，本公开实施例提供一种业务功能节点，其包括：

第四接收模块，用于从上联的业务功能转发节点接收发送节点发送的业务链验证请求信息；

至少一个处理器，配置为根据所述业务链验证请求信息进行验证，得到验证反馈信息；

其中，

在一些实施例中，所述业务功能节点还包括：

第四发送模块，用于将所述验证反馈信息发送给上联的业务功能转发节点，或者，用于将所述验证反馈信息作为验证结果，发送给检查节点。

本公开实施例通过段路由方式发送业务链验证请求信息，其除可让业务链验证请求信息按照预定业务链路径转发外，还可直接通过返回的验证结果确定业务链上各业务功能节点的具体信息，实现对业务链的完整验证(如路径验证和功能验证)。同时，段路由技术中用段标识显式的标明了业务链上的各业务功能转发节点和业务功能节点，且还可以利用段路由的网络编程功能，使验证更加便捷、容易实现。

附图说明

附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其它特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为本公开实施例提供的一种验证业务链的方法的流程图；

图2为本公开实施例提供的另一种验证业务链的方法的流程图；

图3为本公开实施例提供的另一种验证业务链的方法的流程图；

图4为本公开实施例提供的一种验证业务链的方法的流程图；

图5为本公开实施例提供的另一种验证业务链的方法的流程图；

图6为本公开实施例提供的一种验证业务链的方法的流程图；

图7为本公开实施例提供的另一种验证业务链的方法的流程图；

图8为本公开实施例提供的一种发送节点的组成框图；

图9为本公开实施例提供的一种SFF节点的组成框图；

图10为本公开实施例提供的一种SF节点的组成框图；

图11为本公开实施例提供的一种验证业务链的方法所用网络的结构示意图；

图12为本公开实施例提供的一种验证业务链的方法的信息流向图；

图13为本公开实施例提供的另一种验证业务链的方法的信息流向图；

图14为本公开实施例提供的另一种验证业务链的方法的信息流向图；

图15为本公开实施例提供的另一种验证业务链的方法的信息流向图；

图16为本公开实施例提供的另一种验证业务链的方法的信息流向图；

图17为本公开实施例提供的一种业务链的结构逻辑示意图；

图18为本公开实施例提供的一种业务链验证请求信息的结构示意图；

图19为本公开实施例提供的一种SFC INFO报文的结构示意图；

图20为本公开实施例提供的一种带有测试报文的SFC INFO报文的结构示意图。

具体实施方式

为使本领域的技术人员更好地理解本公开实施例的技术方案，下面结合附图对本公开实施例提供的验证业务链的方法、发送节点、业务功能转发节点、业务功能节点进行详细描述。

在下文中将参考附图更充分地描述本公开实施例，但是所示的实施例可以以不同形式来体现，且不应当被解释为限于本公开阐述的实施例。反之，提供这些实施例的目的在于使本公开透彻和完整，并将使本领域技术人员充分理解本公开的范围。

本公开实施例可借助本公开的理想示意图而参考平面图和/或截面图进行描述。因此，可根据制造技术和/或容限来修改示例图示。

在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。

本公开所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本公开所使用的术语“和/或”包括一个或多个相关列举条目的任何和所有组合。如本公开所使用的单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。如本公开所使用的术语“包括”、“由……制成”，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。

除非另外限定，否则本公开所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本公开明确如此限定。

本公开实施例用于能实现服务链(SFC)的段路由(SR)网络中。

参照图11，以上网络包括多个相互连接的业务功能转发(Service FunctionForwarder，SFF)节点，每个SFF节点下属一个或多个业务功能(SF)节点。SFF节点可将报文转发给与其相连的SF节点或SFF节点。而每个SF节点能实现特定的业务功能(SF)，如防火墙(FW)、负载均衡(LB)等。

其中，段路由(SegmentRouting，SR)是一种基于源地址的路由方法，其在多协议标签交换(Multi-Protocol Label Switching，MPLS)网络或互联网协议第6版(InternetProtocol Version 6，IPv6)的报文头中增加段路由报文头(Segment RoutingHeader，SRH)，而SRH中携带有一系列的指示操作(也称为段操作)，用于实现报文在网络中的路由和传输。SRH的指示操作具体可通过其段列表(Segement List)中的多个段标识(Segement ID，SID)实现。

其中，基于SR的MPLS称为SR-MPLS。

而基于SR的IPv6称为SRv6，SRv6的SID是一个128位数，也可以称为SRv6 SID。SRv6SID是一种网络指令(Instruction)，它由Locator(位置)和Function(功能)两部分组成，Locator主要起路由作用，所以要在SR的域内唯一，Function可以表示设备的任何功能(操作)，比如转发、业务等。Rv6 SID的结构更有利于方便的进行网络编程(NetworkProgramming)。

其中，当业务链基于SR实现时，需进行SR业务编排(Service Programming)，即将业务功能(SF)关联到SID，具体是将SID包含在SRH的段列表中，与其它SID一起指定路由，完成业务编排，实现业务链的功能。

其中，若SF节点本身不支持SR功能，则可能需要使用SR代理(Proxy)使其可用于SR，此时可将SF节点和SR代理的整体视为一个支持SR功能的SF节点。

第一方面，本公开实施例提供一种验证业务链的方法，用于发送节点。

本公开实施例用于实现对业务链的验证，而本公开实施例的方法具体用于供发送节点执行。

其中，发送节点可以是网络中的某个特定节点，即专门用于执行本公开实施例的方法的节点；或者，发送节点也可以是网络中的任意常规节点(Classifier节点)，或者说，只要某个节点执行了本公开实施例的方法，其就是发送节点。

参照图1，本公开实施例的方法包括：

S101、发送业务链验证请求信息。

其中，业务链验证请求信息为SR报文，其段列表至少包括待验证SF节点的SID；业务链验证请求信息包括验证请求，验证请求用于要求业务链的业务节点对待验证SF节点进行验证以验证业务链，并向检查节点发送验证结果；业务节点包括SF节点和SFF节点。

网络中的发送节点(Sender)向业务链中发送用于要求进行业务链验证的信息(业务链验证请求信息)，以进行业务链验证。

该业务链验证请求信息为SR报文的形式，其SRH的段列表(Segement List)中包括需要进行验证的SF节点(待验证SF节点)的SID。同时，业务链验证请求信息中还包括要求对待验证SF节点进行验证的“验证请求”。

由此，网络中的各业务节点可根据待验证SF节点的SID将业务链验证请求信息发送至待验证SF节点或其上联的SFF节点，并根据验证请求对待验证SF节点进行所需的验证，再将验证得到的结果(验证结果)发送给特定的检查节点(Reciever)，通过对验证结果的汇总实现对业务链整体的验证(如路径验证和功能验证)。

本公开实施例通过SR方式发送业务链验证请求信息，其除可让业务链验证请求信息按照预定业务链路径转发外，还可直接通过返回的验证结果确定业务链上各SF节点的具体信息，实现对业务链的完整验证(如路径验证和功能验证)。同时，SR技术中用SID显式的标明了业务链上的各SFF节点和SF节点，且还可以利用SR的网络编程功能，使验证更加便捷、容易实现。

当然，应当理解，以上检查节点可为转发平面中的节点(包括发送节点)；也可以是控制平面中的节点，如SDN控制器、集中监控系统等。

当然，应当理解，业务链验证请求信息的段列表“包括待验证SF节点的SID”并不代表其中不包括其它业务节点(SF节点和SFF节点)的SID。

具体的，SR报文根据其段列表中SID进行传输，为实现对待验证SF节点验证，业务链验证请求信息(SR报文)中至少应包括待验证SF节点的SID。但是，业务链验证请求信息也可包括其它的SID，例如沿业务链的路径，从发送节点到待验证SF节点间的所有业务节点的SID，或者是整个业务链中所有业务节点的SID，以更好的限定业务链验证请求信息的传输路径。当然，当业务链验证请求信息中包括“非待验证SF节点”的SID时，业务链验证请求信息不会要求对这些SF节点进行验证。

当然，应当理解，业务链验证请求信息需要通过某些方式表明其中哪些SID对应的是待验证SF节点。

例如，可在业务链验证请求信息中设置表示待验证SF节点在业务链中的跳数的HOP count参数，而业务链验证请求信息经过每个SF节点后HOP count被减1，从而HOPcount为1时到达的SF节点就是待验证SF节点。

或者，也可以是待验证SF节点的SID增加特定的标识；或是在业务链验证请求信息的其它位置单独标明待验证SF节点等。

或者，若业务链验证请求信息只有待验证SF节点的SID，而无其它SF节点的SID，则可认为所有对应SID的SF节点就是待验证SF节点。

参照图2，在一些实施例中，检查节点为发送节点；在发送业务链验证请求信息后，还包括：

S102、接收验证结果。

S103、根据验证结果，验证业务链。

当发送节点同时也是检查节点时，其在发送业务链验证请求信息后，还需要接收验证结果，并根据验证结果业务链的具体状况，完成业务链验证。

在一些实施例中，待验证SF节点包括业务链的多个SF节点。

作为本公开实施例的一种方式，每个业务链验证请求信息中可包括多个待验证SF节点的SID，从而该业务链验证请求信息可依次经过这些SF节点，并实现对这些SF节点的验证，即根据一个业务链验证请求信息可实现对多个SF节点的验证。

在一些实施例中，待验证SF节点为业务链的一个SF节点。

作为本公开实施例的另一种方式，每个业务链验证请求信息仅有一个待验证SF节点的SID，故根据一个业务链验证请求信息仅能对一个SF节点进行验证。

在一些实施例中，业务链验证请求信息还包括用于表明业务链验证请求信息的身份的身份信息，身份信息包括以下至少一项：

身份标识；

与待验证SF节点的SID对应的身份SID。

业务链验证请求信息需要具有身份信息，以供SF节点和SFF节点确定它们接收到的信息是业务链验证请求信息还是其它的常规信息，进而决定是否根据该信息开始验证过程。

作为本公开实施例的一种方式，身份信息可以是一个标识(身份标识)。

例如，身份标识可为在SRH中的FLAG或者TAG字段扩展的特殊标志位，或者为指明报文类型的Next Header等。

或者，作为本公开实施例的另一种方式，身份信息也可为新增的身份SID，该身份SID与每个待验证SF节点的SID对应，表示需要对相应的待验证SF节点进行验证。

具体的，可在SF节点或SFF节点上定义以上身份SID，并将身份SID加入业务链验证请求信息，则SF节点或SFF节点接收业务链验证请求信息后可识别出身份SID，进入特殊处理流程。

具体的，身份SID可以是新增的路由前缀，且本地配置指明其为需特殊处理的SID，具体包括但不限于以下信息：SID值、验证类型(如路径验证、功能验证等)、处理方式(如进入某特殊处理流程)。

或者，也可以是SF节点上不增加路由前缀，而是通过SR的网络编程功能来实现，更具体是通过SF节点本身需要对外通告的Loopcack等接口前缀，配合特殊Function来形成SID，这时SF节点可能存在多条SID表项，具有同样的Locator，但Function不同。这时节点上需要特别的处理方式，在节点收到报文并根据SID匹配到本地Locator后，需要进一步辨识其携带的Function来采取相应的处理行为。

具体的，以上身份信息可表明业务链验证请求信息为OAM信息，需要进入OAM处理流程，从而身份信息可为OAM报文标识。

其中，根据网络运营的实际需要，通常将网络的管理工作划分为3大类，即操作(Operation)、管理(Administration)、维护(Maintenance)，简称OAM(操作维护管理，Operation Administration and Maintenance)。其中，操作主要完成日常网络和业务分析、预测、规划和配置工作；维护主要是对网络及其业务的测试和故障管理等进行的日常操作。

在业务链验证请求信息中，还可包括其它进行验证所需的信息。

例如，业务链验证请求信息中还可有关于检查节点的检查节点信息，其包括检查节点的标识(即表明哪个节点是检查节点)，以及应通过什么方式将验证结果发送至检查节点等。

再如，业务链验证请求信息中还可包括用于完成验证的验证参数信息，如表明要进行什么验证，采用什么验证方式，以及验证中所需适用的信息等。具体的，验证参数信息可包括用于测试SF节点的功能的测试报文，用于路径验证的IP报文(如ICMP/ICMPv6/UDP)等。

具体的，以上验证参数信息(如测试报文)可携带在SRH中，如在SRH中扩展TLV(Optional Type Length Value objects)或子TLV(sub-TLV)。例如，一种携带了扩展TLV的业务链验证请求信息的具体结构可参照图18。

或者，验证参数信息也可携带在ipv6扩展头中，扩展头具体可为DestinationOptions Header、Hop-by-Hop Options Header等形式，该ipv6扩展头封装在业务链验证请求信息中，位于SRH之后，并可用Next Header字段指明。

或者，验证参数信息也可携带在业务链验证请求信息的payload(负载)中，xipayload在段列表之后携带，并用Next Header字段指明。

在一些实施例中，业务链验证请求信息为路径验证请求信息，验证请求用于要求验证待验证SF节点位置和的SF类型。

作为本公开实施例的一种方式，业务链验证请求信息可要求验证业务链的路径，即验证SF节点是否是按预期顺序(即预期的业务链)编排。此时，业务链验证请求信息中的验证请求则要求获取待验证SF节点的SF类型以及其在业务链中所处的位置(或者说顺序)，其中位置可通过待验证SF节点和其上联的SFF节点的SID以及转发顺序体现。由此，验证结果应能表明在业务链中每个位置的待验证SF节点实现的是什么SF，例如是确定防火墙(FW)还是负载均衡(LB)等，故该验证也就确定了业务链的每个位置是哪个SF节点，即验证了业务链路径。

其中，在验证结果中还可包括其它对验证有用的信息，例如SF节点的标识信息(如厂家信息、实例号等，以区分同类型的SF节点)，返回码信息(用于说明发送验证结果的原因，如正常返回、报文错误、找不到下一跳等)等。

从而，检查节点可将接收到的验证结果中的SF节点的信息与业务链中编排(预期)的SF节点的信息进行比较，以确定各SF节点是否可达(若收到了SF节点的SF类型，则SF节点必然可达)，以及确定各SF节点是否按照预期顺序编排。

在一些实施例中，待验证SF节点包括业务链的所有的SF节点。

作为本公开实施例的一种方式，可以是在一个业务链验证请求信息中，将业务链的所有SF节点均作为待验证SF节点(故业务链验证请求信息包括所有SF节点的SID)，从而该业务链验证请求信息依次经过业务链的各业务节点，实现对整个业务链的路径验证。

参照图3，在一些实施例中，待验证SF节点为业务链的一个SF节点；在发送业务链验证请求信息后，还包括：

S104、以业务链的下一个SF节点为待验证SF节点，并返回发送业务链验证请求信息的步骤。

作为本公开实施例的另一种方式，也可以是一个业务链验证请求信息中仅用一个SF节点为待验证SF节点(故业务链验证请求信息仅包括一个待验证SF节点的SID)，从而每个业务链验证请求信息仅验证一个待验证SF节点。

在此情况下，为完成对业务链整体路径的验证，每发出针对一个待验证SF节点的业务链验证请求信息后，发送节点可用之前待验证SF节点的下一跳的SF节点为待验证SF节点，并再次发出业务链验证请求信息；如此重复，直到发出以业务链的最后一个SF节点为待验证SF节点的业务链验证请求信息，即可完成对整个业务链的路径验证。

在一些实施例中，业务链验证请求信息为功能验证请求信息，验证请求用于要求验证待验证SF节点的SF的正常性。

作为本公开实施例的另一种方式，业务链验证请求信息也可用于SF节点的SF的正常性，即验证SF节点是否可正常的实现其加载的功能。

在一些实施例中，待验证SF节点为业务链的一个SF节点。

在进行功能验证时，优选采用每个业务链验证请求信息仅包括一个待验证SF节点的方式。这是因为，功能验证的具体类型和所需的信息(如验证参数信息)较多，将多个SF节点验证用的信息全部在一个业务链验证请求信息中发送比较困难。

其中，由于功能验证不必然要求获知各SF节点的位置(顺序)，故其只要保证每个业务链验证请求信息仅包括一个待验证SF节点即可，而当要验证多个SF节点时，相应的多个业务链验证请求信息可同时发送，而不一定等待上次验证完成再发下一个业务链验证请求信息。

第二方面，本公开实施例提供一种验证业务链的方法，用于SFF节点。

本公开实施例用于实现对业务链的验证，而本公开实施例的方法具体用于供SFF节点执行。

应当理解，当某SFF节点执行本公开实施例的方法时，其下属的节点中必然有至少一个待验证SF节点。

参照图4，本公开实施例的方法包括：

S201、接收发送节点发送的业务链验证请求信息。

S202、根据业务链验证请求信息，对下属的待验证SF节点进行验证。

本公开实施例中，SFF节点接收到以上发送节点发送的业务链验证请求信息后，可根据业务链验证请求信息确定其待验证SF节点包括自身下属的SF节点，从而对该待验证SF节点进行验证。

其中，由于业务链验证请求信息为SR报文，故其在网络中被传输时内容可能发生一些必然的变化，故SFF节点收到的业务链验证请求信息与发送节点发送的业务链验证请求信息的内容可能并不是完全相同，但SFF节点收到的信息仍然可视为业务链验证请求信息。

例如，当业务链验证请求信息的段列表中包括路径上的多个业务节点的SID时，业务链验证请求信息每经过一个业务节点的转发都可进行next(下一跳)操作，如对SRv6形式，需将指针(SL)减1并改变当前的目的地址(Destination Address，DA)；而对SR-MPLS形式，则需要剥离当前标签。因此，业务链验证请求信息在转发过程中目的地址和指针、外层标签栈等可能变化。

其中，业务链验证请求信息可能经过多次转发，且网络中的部分SFF节点可能并没有下属的待验证SF节点，从而它们可能仅按照常规方式转发业务链验证请求信息，而不进行验证。或者，也可能有部分SFF节点在用本公开实施例的方法对下属SF节点进行后，还要将业务链验证请求信息进一步用常规方式转发至后续的SFF节点。

在一些实施例中，在对下属的待验证SF节点进行验证后，还包括：向检查节点发送验证结果。

作为本公开实施例的一种方式，在SFF节点对下属待验证SF节点进行验证后，还可由SFF节点自己将验证结果发送给检查节点。

如前，检查节点的形式是多样的，SFF节点(或SF节点)向检查节点发送验证结果的方式也是多样的。

例如，验证结果可为SR报文，也可为ICMP/ICMPv6/UDP等其它形式的报文。

例如，若检查节点是转发平面中的节点，可根据业务链验证请求信息中的源地址确认检查节点的目的地址；而若检查节点是控制平面中的节点(如SDN控制器)，则可通过netconf等协议用控制通道上送验证结果。

在一些实施例中，业务链验证请求信息为路径验证请求信息，验证请求用于要求验证待验证SF节点的位置和SF类型；对下属的待验证SF节点进行验证(S202)包括：

S2021、根据业务链验证请求信息中的待验证SF节点，在本地预存的信息表中查询到下属的待验证SF节点的位置和SF类型。

S2022、根据待验证SF节点的位置和SF类型得到验证结果，并向检查节点发送验证结果。

作为本公开实施例的一种方式，路径验证时，可在SFF节点中预设信息表(如在转发表中增加，或增加与转发表关联的属性表)，其中存储有各SF节点的相关信息(至少包括SF类型和位置)，从而SFF节点可在信息表中直接查询到自身下属的待验证SF节点对应的信息，并根据这些信息得到验证结果，将验证结果发送给检查节点。

从而，验证由SFF节点自身完成，即验证过程中不需要向SF节点发送任何信息。

在一些实施例中，对下属的待验证SF节点进行验证(S202)包括：

S2023、根据业务链验证请求信息中的待验证SF节点，向下属的待验证SF节点发送验证信息。

作为本公开实施例的另一种方式，也可以是SFF节点向下属的待验证SF节点发送用于对其进行验证的信息，从而验证通过SFF节点、SF节点的交互完成。

其中，验证信息是指用于供待验证SF节点完成验证的信息，根据验证方式、待验证SF节点情况的不同，其具体形式也可有不同。

在一些实施例中，向下属的待验证SF节点发送验证信息(S2023)包括：将业务链验证请求信息作为验证信息转发给下属的待验证SF节点。

作为本公开实施例的一种方式，当待验证SF节点本身具有处理业务链验证请求信息的能力时，SFF节点可直接将业务链验证请求信息转发给下属的待验证SF节点，由待验证SF节点根据业务链验证请求信息进行验证。

例如，可以是待验证SF节点收到业务链验证请求信息后识别出需要进行验证，从而对自身进行验证(如得到自身的SF类型信息或验证自身的SF是否正常)，并向SFF节点发送验证反馈信息，或将验证结果发送给检查节点(包括直接发送，或通过SFF节点转发)。

在一些实施例中，向下属的待验证SF节点发送验证信息(S2023)包括：根据业务链验证请求信息产生验证信息，向下属的待验证SF节点发送验证信息。

作为本公开实施例的另一种方式，当待验证SF节点本身没有处理业务链验证请求信息的能力时，则需要SFF节点根据业务链验证请求信息产生能被待验证SF节点处理的信息作为验证信息。

例如，功能验证时，可以是SFF节点可从业务链验证请求信息中提取出测试报文作为验证信息发给待验证SF节点，该测试报文是直接供SF节点的SF处理的报文。

例如，待验证SF节点的SF为防火墙(FW)，用于按照过滤规则过滤报文，则测试报文可包括在过滤规则范围内的报文和不在过滤规则范围内的报文，从而SFF节点可根据将测试报文发送给待验证SF节点后，在预定时间内是否收到待验证SF节点发回的报文，判断防火墙是否正常工作。

参照图5，在一些实施例中，在向下属的待验证SF节点发送验证信息(S202)后，还包括：

S203、接收待验证SF节点的验证反馈信息。

S204、根据验证反馈信息得到验证结果，并向检查节点发送验证结果。

如前，在SFF节点向下属的待验证SF节点发送验证信息后，可能是待验证SF节点自身完成验证，并将验证结果发送给检查节点(包括通过SFF节点转发)。也有可能是，待验证SF节点自身无法直接得出给检查节点的验证结果，从而其可将与验证结果相关的信息(验证反馈信息)发给SFF节点，而SFF节点再根据该验证反馈信息得出正式的验证结果并发给检查节点。

例如，当SFF节点根据以上待验证SF节点发回的报文判断防火墙的功能是否正常时，就可将防火墙的功能是否正常的结论作为验证结果，发送给检查节点，而不是将待验证SF节点发回的报文直接发给检查节点。

第三方面，本公开实施例提供一种验证业务链的方法，用于SF节点。

本公开实施例用于实现对业务链的验证，而本公开实施例的方法具体用于供SF节点执行。

应当理解，当某SF节点执行本公开实施例的方法时，其必然就是待验证SF节点。

参照图6，本公开实施例的方法包括：

S301、从上联的SFF节点接收发送节点发送的业务链验证请求信息。

S302、根据业务链验证请求信息进行验证，得到验证反馈信息。

当某个SFF节点为待验证SF节点时，其可从上联的SFF节点接收发送节点发送的业务链验证请求信息，并根据业务链验证请求信息对自身进行验证，得到与验证结果相关的验证反馈信息。

如前，此时SF节点收到的业务链验证请求信息与发送节点发出的业务链验证请求信息的内容可能并不完全相同，但其仍视为业务链验证请求信息。

参照图7，在一些实施例中，在根据业务链验证请求信息进行验证，得到验证反馈信息(S302)后，还包括：

S303、将验证反馈信息发送给上联的SFF节点。

如前，作为本公开实施例的一种方式，SF节点在得出验证反馈信息后，可将其发送给上联的SFF节点，由SFF节点根据验证反馈信息得出验证结果并发送给检查节点。

或者，参照图7，在一些实施例中，在根据业务链验证请求信息进行验证，得到验证反馈信息(S302)后，还包括：

S303、将验证反馈信息作为验证结果，发送给检查节点。

如前，作为本公开实施例的另一种方式，SF节点也可将验证反馈信息后作为验证结果，自己发送给检查节点(包括通过SFF节点转发)。

第四方面，参照图8，本公开实施例提供一种实现上述方法的发送节点，其包括：

第一发送模块，用于发送业务链验证请求信息；

其中，

业务链验证请求信息为SR报文，其段列表至少包括待验证SF节点的SID；业务链验证请求信息包括验证请求，验证请求用于要求业务链的业务节点对待验证SF节点进行验证以验证业务链，并向检查节点发送验证结果；业务节点包括SF节点和SFF节点。

在一些实施例中，发送节点还包括：

第一接收模块，用于接收验证结果；

至少一个处理器，配置为根据验证结果，验证业务链。

第五方面，参照图9，本公开实施例提供一种实现上述方法的SFF节点，其包括：

至少一个处理器，配置为根据业务链验证请求信息，对下属的待验证SF节点进行验证；

其中，

在一些实施例中，SFF节点还包括：

第二发送模块，用于向检查节点发送验证结果。

在一些实施例中，SFF节点还包括：

第三发送模块，用于根据业务链验证请求信息中的待验证SF节点，向下属的待验证SF节点发送验证信息。

在一些实施例中，SFF节点还包括：

第三接收模块，用于接收待验证SF节点的验证反馈信息；

处理器还配置为根据验证反馈信息得到验证结果，并向检查节点发送验证结果。

第六方面，参照图10，本公开实施例提供一种实现上述方法的SF节点，其包括：

第四接收模块，用于从上联的SFF节点接收发送节点发送的业务链验证请求信息；

至少一个处理器，配置为根据业务链验证请求信息进行验证，得到验证反馈信息；

其中，

在一些实施例中，SF节点还包括：

第四发送模块，用于将验证反馈信息发送给上联的SFF节点，或者，用于将所述验证反馈信息作为验证结果，发送给检查节点。

具体实施例1

本实施例的具体的验证业务链的方法可包括以下的步骤：

A101、发送节点构造并发送业务链验证请求信息。

其中，发送节点先获取待验证业务链的业务节点(SFF节点和SF节点)的SID，以确定待验证SF节点。

具体的，待验证业务链的业务节点的SID可从本地获取，也可由控制平面进行配置。

其中，发送节点还需将身份信息(身份SID、身份标识)加入业务链验证请求信息，以表明业务链验证请求信息的身份。

其中，发送节点还需将检查节点信息、验证参数信息等加入业务链验证请求信息。

其中，业务链验证请求信息携带身份信息、检查节点信息、验证参数信息等的方式可如前，在此不再详细描述。

A102、业务链上对应的业务节点识别业务链验证请求信息，进行相应的处理(如转发、验证等)，生成验证结果并发送给检查节点。

其中，每个业务节点接收到一个信息后进行的工作可包括：

(1)业务节点判断信息的当前SID(目的地址)是否为本地SID，若否则转发信息至目的地址，若是则进入下一步。

(2)业务节点判断当前SID是否为身份SID(如表示报文为OAM报文的SID)，若是则确定业务链验证请求信息为对本地SID的SF节点进行验证的业务链验证请求信息，故进入验证过程，若否则进入下一步骤。

(3)业务节点判断信息中是否有身份标识，若是则确定业务链验证请求信息为对本地SID的SF节点进行验证的业务链验证请求信息，故进入验证过程，若否则按照常规报文处理。

当然，以上步骤(2)、(3)都是为了确定信息是否为针对本地的业务链验证请求信息，故其顺序可以互换，也可根据业务链验证请求信息的可能情况，仅进行其中的一个步骤。

A103、检查节点根据收到的验证结果验证业务链。

检查节点在接收到验证结果后，即可根据验证结果对业务链进行验证。

例如，对路径验证，检查节点可将接收到的验证结果中的待验证SF节点的顺序(位置)、SF类型与预期的业务链中的相应信息进行比较，以确定预期的业务链的路径的正确性。

例如，对功能验证，检查节点可根据验证结果中对待验证SF节点的SF是否正常的判断，确定业务链的功能是否正常。

当然，如果是超过预定时间还未收到针对某待验证SF节点的验证结果，则可判断该待验证SF节点存在问题(例如判断其不可达)。

具体实施例2

本实施例用于业务链的路径验证，具体是通过SF节点和SFF节点的交互实现路径验证。

参照图11，本实施例的网络中发送节点连接第一业务功能转发节点(SFF1)，而SFF1连接第二业务功能转发节点(SFF2)；SFF1下属有第一业务功能节点(SF1)和第二业务功能节点(SF2)，SFF2下属有第三业务功能节点(SF3)；同时，SFF1和SFF2均连接检查节点。

应当理解，本实施例只是在逻辑上将发送节点和检查节点视为两个不同节点进行描述，而二者的实体可为一个节点。

本实施例中，以待验证的业务链为SF1-->SF2-->SF3为例进行说明。

参照图12，本实施例的具体的验证业务链的方法可包括以下的步骤

A201、发送节点构造并发送业务链验证请求信息。

由此，业务链验证请求信息可包括：

<S,SFF1><SFF1,SF1,SF2,SFF3,SF2；SL＝4；NH＝SFC INFO><SFC INFO>；

其中，S表示发送节点的SID，其它各SF或SFF表示相应业务节点的SID，SL为指针，SFC INFO表示验证参数信息，具体是携带在SRH后的报文。

具体的，SFC INFO报文的结构可参照图19，其中Pkt Type表示报文类型，ReturnCode表示返回验证结果的方式，业务链的详细信息以各SF节点的ID为父节点记录。

或者，业务链验证请求信息可也包括：

<S,SFF1><SFF1,END.OAMP,SF1,END.OAMP,SF2,SFF2,END.OAMP,SF3；SL＝7；TLV＝SFC INFO>

其中，END.OAMP为身份SID，而验证参数信息(SFC INFO)携带在TLV中。

以下以业务链验证请求信息为以上第一种形式为例，进行描述。

A202、SFF1收到业务链验证请求信息后，发现目的地址(DA)为本地SID，执行next操作更新报文头(SR-MPLS中剥离当前标签，SRv6中替换目的地址及指针减一)，查询本地转发表，将业务链验证请求信息从与SF1相连的端口/链路发送出去。

SFF1转发给SF1的业务链验证请求信息可包括：

<S,SF1><SFF1,SF1,SF2,SFF2,SF3；SL＝3；NH＝SFC INFO><SFC INFO>。

A203、SF1收到业务链验证请求信息后，识别出其是路径验证请求信息(如通过NH＝SFC INFO识别)，进入OAM处理流程，将自己的SID(为自身位置信息的一部分)和SF类型等信息(SF1_info)加入业务链验证请求信息中，执行next操作，将路径验证请求信息原路返回给SFF1。

SF1返回给SFF1的业务链验证请求信息可包括：

<S,SF2><SFF1,SF1,SF2,SFF2,SF3；SL＝2；NH＝SFC INFO><SFC INFO：SF1_info>。

其中，SRH的内容也就是表明了SF1的位置，后续不再详细描述。

A204、SFF1收到SF1发回的业务链验证请求信息后，查询转发表，发现目的地址为SF2的SID，将业务链验证请求信息转发给SF2。

SFF1转发给SF2的业务链验证请求信息可包括：

<S,SF2><SFF1,SF1,SF2,SFF2,SF3；SL＝2；NH＝SFC INFO><SFC INFO：SF1_info>。

A205、SF2收到业务链验证请求信息，识别出其是路径验证请求信息，进入OAM处理流程，将自己的SID和SF类型等信息(SF2_info)加入业务链验证请求信息中，执行next操作，将路径验证请求信息原路返回给SFF1。

SF2返回给SFF1的业务链验证请求信息可包括：

<S,SFF2><SFF1,SF1,SF2,SFF2,SF3；SL＝1；NH＝SFC INFO><SFC INFO：SF1_info，SF2_info>。

A206、SFF1收到SF2返回的路径验证请求信息后查询转发表，发现下一跳不是本地SID，故构造验证结果，并将验证结果发送给检查节点。

验证结果包括本节点的信息(SFF1_info)和以上SF1、SF2的信息，且能表明SF1、SF2在业务链上的先后顺序。

其中，验证结果还可包括用于返回原因的返回码等，在此不再详细描述。

其中，验证结果还可包括与业务链验证请求信息对应的标识符，用于在有多个验证结果时，表明各验证结果是针对哪个业务链验证请求信息做出的。

具体的，验证结果可封装在ICMP中，且携带原路径验证请求信息的SRH，其可包括：

<SFF1,R>ICMPV6<SFF1,SF1,SF2,SFF2,SF3；SL＝1；NH＝SFC INFO><SFC INFO：SF1_info，SF2_info，SFF1_info>。

其中，R表示检查节点的SID。

A207、SFF1还发现路径验证请求信息的下一跳为SFF2，故查询转发表，将路径验证请求信息继续从与SFF2相连的端口/链路发送出去。

SFF1转发给SFF2的业务链验证请求信息可包括：

<S,SFF2><SFF1,SF1,SF2,SFF2,SF3；SL＝1；NH＝SFC INFO><SFC INFO：SF1_info，SF2_info，SFF1_info>。

A208、与以上类似，SFF2将路径验证请求信息发送给SF3。

SFF2转发给SF3的路径验证请求信息可包括：

<S,SF3><SFF1,SF1,SF2,SFF2,SF3；SL＝1；NH＝SFC INFO><SFC INFO：SF1_info，SF2_info，SFF1_info>。

A209、与以上类似，SF3将自身的SF类型等信息(SF3_info)加入路径验证请求信息后原路返回给SFF2。

SF3返回给SFF2的路径验证请求信息可包括：

<S,SFF2><SFF1,SF1,SF2,SFF2,SF3；SL＝1；NH＝SFC INFO><SFC INFO：SF1_info，SF2_info，SFF1_info；SF3_info>。

A210、与以上类似，SFF2将自身信息(SFF2_info)加入验证结果，并将验证结果发送给检查节点。

SFF2发给检查节点的验证结果可包括：

<SFF2,R>ICMPV6<SFF1,SF1,SF2,SFF2,SF3；SL＝0；NH＝SFC INFO><SFC INFO：SF1_info，SF2_info，SFF1_info；SF3_info，SFF2_info>。

其中，由于段列表中不再存在下一条，故SFF2不再转发该路径验证请求信息。

具体实施例3

本实施例用于业务链的路径验证，具体是通过SFF节点自身预存的信息实现路径验证。

参照图11，本实施例的网络与以上实施例类似。

A301、发送节点构造并发送业务链验证请求信息。

A302、SFF1收到业务链验证请求信息后，识别出其为业务链验证请求信息，在本地预存的信息表(如在转发表中增加，或增加与转发表关联的属性表)中查询到SF1的位置和SF类型，将其加入业务链验证请求信息，之后执行next操作更新报文头；重复以上过程，将SF2的位置和SF类型加入业务链验证请求信息中，发现没有待处理的本地SID，构造验证结果发送给检查节点。

A303、SFF1发现路径验证请求信息的下一跳为SFF2，故查询转发表，将路径验证请求信息继续从与SFF2相连的端口/链路发送出去。

A304、SFF2收到业务链验证请求信息后，处理方式与A302类似，将SF3的信息(位置和SF类型)加入路径验证请求信息，之后构造并发送验证结果给检查节点。

具体实施例4

本实施例中，每个业务链验证请求信息仅包括一个待验证SF节点的SID，从而要通过多次发送业务链验证请求信息，完成对整个业务链的验证。

参照图11，本实施例的网络与以上实施例类似。

参照图14，本实施例的具体的验证业务链的方法可包括以下的步骤

A401、发送节点构造并发送业务链验证请求信息。

其中，业务链验证请求信息的段列表中可包括业务链所有业务节点的SID，也可仅包括从发送节点到当前的待验证SF节点的SID；但不论具体包括哪些SID，其中仅有一个SF节点为待验证SF节点。

业务链验证请求信息中可设置HOP count参数以确定第几跳SF节点是当前的待验证SF节点，故此时将HOP count设为1。

A402、SFF1接收到业务链验证请求信息，查询转发表，按正常SR转发流程把业务链验证请求信息转发给SF1。

A403、SF1识别业务链验证请求信息，将自己的位置和SF类型等信息加入到业务链验证请求信息中，将HOP count减1(该步骤也可由SFF1进行)，然后将业务链验证请求信息返回给SFF1.

A404、SFF1确定Hop count为0，故根据业务链验证请求信息构造验证结果发送给检查节点。

A405、在检查节点接收到第一个验证结果后，发送节点发送第二个业务链验证请求信息，其中HOP count设置为2。

其中，发送节点应当能获知检查节点已经得到了验证结果，例如发送节点就是检查节点。

A406、SFF1接收到业务链验证请求信息并将其转发给SF1。

A407、SF1因发现HOP count为2，确定该业务链验证请求信息不是针对自身的，故将HOP count减1，并返回业务链验证请求信息(也可将自己的SF类型等信息加入到业务链验证请求信息)。

A408-A410、与步骤A402至A404类似，SFF1将业务链验证请求信息发给SF2，SF2将自己的位置和SF类型等信息加入到业务链验证请求信息中，将HOP count减1，然后将业务链验证请求信息返回给SFF1，SFF1确定HOP count为0，故根据业务链验证请求信息构造验证结果发送给检查节点。

后续步骤与之前类似，发送节点再将HOP count加1(即为HOP count3)后第三次发送业务链验证请求信息，业务链验证请求信息依次经过SFF2、SF1、SFF1、SF2、SFF1后被发送到SFF2，且HOP count变为1，故SFF2与SF3间进行交互，完成对SF3的验证，第三次反馈验证结果。

总之，发送节点发送的业务链验证请求信息中，每次将HOP count加1；SFF节点在HOP count为0时构造验证结果，不为0时仅转发业务链验证请求信息；SF节点则将经过的业务链验证请求信息中的HOP count减1后返回，并至少在HOP count为1时将自身的位置和SF类型等信息加入业务链验证请求信息(HOP count为其它值时也可加入)。由此，即可保证每次验证的都是比前一次多一跳的SF节点。

当然，参照图15，本实施例也可采用由SFF节点独自完成验证的方式(如针对路径验证时)，其与以上方式的区别在于不必将业务链验证请求信息发送给SF节点，而由SFF节点自身改变HOP count并得出验证结果，故在此不再详细描述。

具体实施例5

本实施例用于对SF节点的SF是否正常进行验证，由于SF的类型非常多，验证中所需的处理差别也非常大，故发送一个业务链验证请求信息验证多个SF节点比较困难，因此本实施例采用每个业务链验证请求信息仅包括一个待验证SF节点的SID的方式。

参照图11，本实施例的网络与以上实施例类似。

本实施例中，仅以验证SF3为例进行说明，也可认为即业务链仅包括SF3，或者认为只有SF3为待验证SF节点。

参照图16，本实施例的具体的验证业务链的方法可包括以下的步骤

A501、发送节点构造并发送业务链验证请求信息。

因业务链中仅有SF3，故业务链验证请求信息中仅包括SFF2和SF3的SID。

A502、SFF2接收到业务链验证请求信息并识别其身份，并向SF3发送验证信息。

其中，当SF3具有直接处理业务链验证请求信息的能力(如有额外的OAM功能)时，则SFF2可直接将业务链验证请求信息转发给SF3，即验证信息就是业务链验证请求信息。

当SF3没有直接处理业务链验证请求信息的能力时，则SFF2需要生成能直接供SF3处理的测试报文，将测试报文发送给SF3供其处理，即验证信息就是测试报文。

例如，SF2可提取出业务链验证请求信息中的测试报文，将其加上外层封装(如vlan标签、vxlan头等)后发送给SF3。

其中，测试报文是验证参数信息，故其可被加在以上SFC INFO中，带有测试报文(SF Confirm Info)的SFC INFO报文的结构可参照图20所示。

其中，根据要测试的SF的不同，测试报文的具体形式也可不同。

例如，若SF3的SF为网络地址转换(NAT)，则测试报文中可携带源IP、源端口、目的IP、目的端口等。

再如，若SF3的SF为配置了过滤规则的防火墙(FW)，则测试报文可包括在过滤规则范围内的报文和不在过滤规则范围内的报文。

再如，测试报文也可以是与SF3约定的特殊报文，SF3收到该特殊报文后根据当前情况返回SF功能是否运行正常的说明。

A503、SF3根据验证信息产生的验证反馈信息，并将其发送给SFF2。

其中，当SF3具有直接处理业务链验证请求信息的能力时，其可直接将自身SF是否正常的说明加入业务链验证请求信息中，并将业务链验证请求信息返回给SFF2，即反馈信息就是业务链验证请求信息。

当SF3没有直接处理业务链验证请求信息的能力时，其会按照自身的SF处理测试报文，即SF3会将测试报文当作常规报文用自身SF进行处理(例如地址转换、防火墙过滤等)，并向SFF2发送反馈信息。

A504、SFF2根据验证反馈信息构造验证结果，并将验证结果发送给检查节点。

其中，当SF3具有直接处理业务链验证请求信息的能力时，SFF2可从来自SF3的业务链验证请求信息中获取SF3的SF的正常性，并构造验证结果。

其中，当SF3没直接处理业务链验证请求信息的能力时，则SFF2可分析SF3对测试报文的反馈，以确定SF3的SF的正常性，并构造验证结果。

例如，若SF3的SF为网络地址转换(NAT)，则SFF2可判断其回复的报文中的IP/端口是否被转变为了正确的值，以确定网络地址转换的SF是否正常。

再如，若SF3的SF为防火墙(FW)，则SFF2可通过在预定时间内是否收到了不在过滤规则范围内的报文(其不应被过滤)，且没有收到在过滤规则范围内的报文(其应当被过滤)，判断防火墙的功能是否正常。

当然，若要验证SF1、SF2时，可用类似方法直接分别SF1和SF2，在此不再详细描述。

本领域普通技术人员可以理解，上文中的处理器为具有数据处理能力的器件，其包括但不限于中央处理器(CPU)等。

本领域普通技术人员可以理解，上文中所公开的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。

某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器(CPU)、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)或其它磁盘存储器；只读光盘(CD-ROM)、数字多功能盘(DVD)或其它光盘存储器；磁盒、磁带、磁盘存储或其它磁存储器；可以用于存储期望的信息并且可以被计算机访问的任何其它的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其它传输机制之类的调制数据信号中的其它数据，并且可包括任何信息递送介质。

本公开已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其它实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims

1.一种验证业务链的方法，用于发送节点，所述方法包括：

发送业务链验证请求信息；

其中，

2.根据权利要求1所述的方法，其中，所述检查节点为发送节点；在所述发送业务链验证请求信息后，还包括：

接收所述验证结果；

根据所述验证结果，验证所述业务链。

3.根据权利要求1所述的方法，其中，

所述待验证业务功能节点包括业务链的多个业务功能节点；

或者，

所述待验证业务功能节点为业务链的一个业务功能节点。

4.根据权利要求1所述的方法，其中，所述业务链验证请求信息还包括用于表明业务链验证请求信息的身份的身份信息，所述身份信息包括以下至少一项：

身份标识；

与待验证业务功能节点的段标识对应的身份段标识。

5.根据权利要求1所述的方法，其中，

所述业务链验证请求信息为路径验证请求信息，所述验证请求用于要求验证待验证业务功能节点的位置和业务功能的类型。

6.根据权利要求5所述的方法，其中，

所述待验证业务功能节点包括业务链的所有的业务功能节点。

7.根据权利要求5所述的方法，其中，所述待验证业务功能节点为业务链的一个业务功能节点；

在所述发送业务链验证请求信息后，还包括：

8.根据权利要求1所述的方法，其中，

所述业务链验证请求信息为功能验证请求信息，所述验证请求用于要求验证待验证业务功能节点的业务功能的正常性。

9.根据权利要求8所述的方法，其中，所述待验证业务功能节点为业务链的一个业务功能节点。

10.一种验证业务链的方法，用于业务功能转发节点，所述方法包括：

接收发送节点发送的业务链验证请求信息；

其中，

所述业务链验证请求信息为段路由报文，其段列表至少包括待验证业务功能节点的段标识；所述业务链验证请求信息包括验证请求，所述验证请求用于要求业务链的业务节点对待验证业务功能节点进行验证以验证业务链，并向检查节点发送验证结果；所述

包括业务功能节点和业务功能转发节点。

11.根据权利要求10所述的方法，其中，在所述对下属的待验证业务功能节点进行验证后，还包括：

向所述检查节点发送验证结果。

12.根据权利要求10所述的方法，其中，所述业务链验证请求信息为路径验证请求信息，所述验证请求用于要求验证待验证业务功能节点的位置和业务功能的类型；所述对下属的待验证业务功能节点进行验证包括：

13.根据权利要求10所述的方法，其中，所述对下属的待验证业务功能节点进行验证包括：

14.根据权利要求13所述的方法，其中，在所述向下属的待验证业务功能节点发送验证信息后，还包括：

接收所述待验证业务功能节点的验证反馈信息；

15.根据权利要求13所述的方法，其中，所述向下属的待验证业务功能节点发送验证信息包括：

16.根据权利要求13所述的方法，其中，所述向下属的待验证业务功能节点发送验证信息包括：

17.一种验证业务链的方法，用于业务功能节点，所述方法包括：

其中，

所述业务链验证请求信息为段路由报文，其段列表至少包括待验证业务功uw能节点的段标识；所述业务链验证请求信息包括验证请求，所述验证请求用于要求业务链的业务节点对待验证业务功能节点进行验证以验证业务链，并向检查节点发送验证结果；所述业务节点包括业务功能节点和业务功能转发节点。

18.根据权利要求17所述的方法，其中，在所述根据所述业务链验证请求信息进行验证，得到验证反馈信息后，还包括：

将所述验证反馈信息发送给上联的业务功能转发节点。

19.根据权利要求17所述的方法，其中，在所述根据所述业务链验证请求信息进行验证，得到验证反馈信息后，还包括：

将所述验证反馈信息作为验证结果，发送给检查节点。

20.一种发送节点，其包括：

第一发送模块，用于发送业务链验证请求信息；

其中，

21.根据权利要求20所述的发送节点，还包括：

第一接收模块，用于接收所述验证结果；

22.一种业务功能转发节点，其包括：

其中，

23.根据权利要求22所述的业务功能转发节点，还包括：

第二发送模块，用于向所述检查节点发送验证结果。

24.根据权利要求22所述的业务功能转发节点，还包括：

25.根据权利要求24所述的业务功能转发节点，还包括：

26.一种业务功能节点，其包括：

其中，

27.根据权利要求26所述的业务功能节点，还包括