CN107148768A - 用于数据路径确认与验证的系统和方法 - Google Patents

Abstract

一种用于操作源节点的方法，包括：接收数据路径确认请求命令，数据路径确认请求命令用于请求确认与标识于该数据路径确认请求命令中的业务流相关联的路径，以及根据被确认的该路径确定第一跳序列，其中，该第一跳序列和与非确认请求分组相关联的第二跳序列相同，该非确认请求分组与被确认的该路径相关联。该方法还包括该源节点根据该数据路径确认请求命令生成确认请求分组，该确认请求分组包括与该第一跳序列相关联的路由信息、设置为指定值的告警标识以及路径确认报头，路径确认报头指定由接收该确认请求分组的节点执行的处理；以及源节点根据该路由信息发送该确认请求分组。

Description

用于数据路径确认与验证的系统和方法

本申请要求享有于2014年11月5日提交的、申请号为14/533,729、名称为“用于数据路径确认与验证的系统与方法”的美国正常专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本公开一般涉及数字通信，更具体地涉及用于数据路径确认和验证的系统和方法。

背景技术

通常，可靠的路由路径可能在一点上变得不可靠或甚至不可用。数据路径确认和验证是网络操作的关键阶段，有助于确保通信系统的正常运行。

发明内容

本公开的示例性实施例提供了用于数据路径确认和验证的系统和方法。

根据本公开的示例性实施例，提供了一种用于操作源节点的方法。该方法包括源节点接收数据路径确认请求命令，该数据路径确认请求命令用于请求确认与标识于该数据路径确认请求命令中的业务流相关联的路径，并且源节点根据被确认的该路径，确定第一跳序列，其中，该第一跳序列与被确认的路径相关联的非确认请求分组相关联的第二跳序列相同。该方法还包括源节点根据数据路径确认请求命令生成确认请求分组，确认请求分组包括与第一跳序列相关联的路由信息、设置为指定值的告警标识以及路径确认报头，该路径确认报头指定由接收确认请求分组的节点执行的处理；以及源节点根据路由信息发送确认请求分组。

根据本公开的另一示例性实施例，提供了一种用于操作节点的方法。该方法包括该节点接收确认请求分组，该确认请求分组包括设置为指定值的告警标识、用于确认请求分组的跳序列、指定跳序列中的当前跳的跳索引、跳序列中的跳数和路径确认报头，该路径确认报头指定由接收确认请求分组的节点执行的处理；以及该节点根据路径确认报头进行处理以产生结果。

根据本公开的另一示例性实施例，提供了源节点。该源节点包括接收器、可操作地耦合到接收器的处理器、以及可操作地耦合到处理器的发送器。接收器接收数据路径确认请求命令，其请求验证与在数据路径确认请求命令中识别的业务流相关联的路径。处理器根据被确认的路径确定第一跳序列，其中，第一跳序列与被确认的路径相关联的非确认请求分组相关联的第二跳序列相同，并且根据数据路径确认请求命令生成确认请求分组，该确认请求分组包括与第一跳序列相关联的路由信息、设置为指定值的告警标识以及路径确认报头，该路径确认报头指定由接收确认请求分组的节点执行的处理。发送器根据路由信息发送确认请求分组。

根据本公开的另一示例性实施例，提供了节点。该节点包括接收器和可操作地耦合到接收器的处理器。接收器接收确认请求分组，该确认请求分组包括设置为指定值的告警标识、用于确认请求分组的跳序列、以及路径确认报头，该路径确认报头指定由接收确认请求分组的节点执行的处理。处理器根据路径确认报头进行处理以产生结果。

本实施例的一个优点是对预期路径执行数据路径确认和验证。此外，还可以验证数据路径对称性。

实施例的另一优点是可以执行不同类型的动作，并且记录所得到的信息以供请求节点进行后续处理。

实施例的另一个优点是单个请求和相应的回复可以获得用于数据路径确认和验证的所有所需的信息。

附图说明

为了更完整地理解本公开及其优点，现结合附图参考以下描述，其中：

图1示出了根据本文描述的示例性实施例的示例性通信系统；

图2示出了根据本文描述的示例性实施例的在基于索引的源路由通信系统中使用的示例性分组；

图3示出根据本文描述的示例性实施例的示例性通信系统，突出显示从源节点到目的节点的分组的路径；

图4示出了根据本文描述的示例性实施例的示例性确认请求分组；

图5示出了根据本文描述的示例性实施例的通信系统，突出显示确认请求分组的路径；

图6a示出了根据本文描述的示例性实施例的突出显示确认请求分组的有效载荷的通信系统，其中，在确认请求分组遍历该通信系统时反向路径和前向路径相同；

图6b示出了根据本文描述的示例性实施例的突出显示确认请求分组的有效载荷的通信系统，其中，在确认请求分组遍历该通信系统时反向路径和前向路径不同；

图7示出根据本文描述的示例性实施例的在对称请求的情况下的示例性确认请求分组；

图8示出根据本文描述的示例性实施例的在参与数据路径确认和验证的源节点中发生的示例性操作的流程图；

图9示出了根据本文描述的示例性实施例的在处理分组的节点中发生的示例性操作的流程图；

图10示出了根据本文描述的示例性实施例的示例性第一通信设备；以及

图11示出了根据本文描述的示例性实施例的示例性第二通信设备。

具体实施方式

下面详细讨论当前示例性实施例的操作及其结构。然而，应当理解，本公开提供了可以在各式具体上下文中体现的多种可应用的发明概念。所讨论的具体实施例仅仅表示本公开的具体结构及操作方式，并非限制本公开的范围。

本公开的一个实施例涉及数据路径确认和验证。例如，源节点接收数据路径确认请求命令，该数据路径确认请求命令用于请求确认与标识于该数据路径确认请求命令中的业务流相关联的路径，并且根据被确认的路径确定第一跳序列，其中，第一跳序列与第二跳序列相同，该第二跳序列与被确认的路径相关联的非确认请求分组相关联。源节点还根据数据路径确认请求命令生成确认请求分组，该确认请求分组包括与第一跳序列相关联的路由信息、设置为指定值的告警标识、以及路径确认报头，该路径确认报头指定由接收确认请求分组的节点执行的处理，并且根据路由信息发送确认请求分组。

参考具体上下文中的示例性实施例来描述本公开，即，使用基于索引的源路由以在源节点和目的节点之间路由分组的软件定义网络(software definednetworks，SDN)来描述本公开。本公开可以应用于标准兼容通信系统和非标准兼容通信系统，其使用基于索引的源路由在源节点和目的节点之间进行路由分组。

图1示出了示例性通信系统100。通信系统100可以包括多个节点，诸如节点105、节点107、节点109、节点111、节点113、节点115、节点117、节点119等。通信系统100中的节点可以具有有线和/或无线互连方式。作为说明性示例，节点105可以以有线互连方式连接到节点107和节点109，而节点109可以以无线互连方式连接到节点115。一些节点可以具有有线互联方式和无线互连方式。作为说明性示例，节点119无线地连接到节点115，而节点109有线地连接到节点119。应当理解，虽然通信系统可以使用大量节点，但是为了简单，仅示出相对少量的节点。

在基于索引的源路由中，分组的源节点生成分组的路由。换句话说，分组的源节点指定分组的数据路径。可以通过指定当分组从源节点移动到目的节点时采用的链路序列(或等效跳)来指定分组的数据路径。作为说明性示例，第一跳可以指定从源节点到第一中间节点的链路，第二跳可以指定从第一中间节点到第二中间节点的链路，以此类推，直到第N跳，其可以指定从第N中间节点到目的节点的链路。

图2示出了在基于索引的源路由通信系统中使用的示例性分组200。分组200包括分组报头，该分组报头包括下一跳索引字段205，总跳数字段210和跳大小字段215。分组200还包括N个跳字段(例如：跳1字段220、跳2字段222和跳N字段224)和有效载荷字段230。下一跳索引字段205可以存储用作分组200的下一跳指针的值。总跳计数字段210可以存储指示分组200的总跳数的值。跳大小字段215可以存储指示每个单独跳大小的值。跳字段(例如：跳1字段220、跳2字段222和跳N字段224)可以存储指示分组200在离开节点时要使用的链路(或跳)的值。有效载荷字段230可以存储分组200的数据和/或控制信息。

图3示出了通信系统300，其突出显示了从源节点到目的节点的分组的路径。图3示出了通信系统300的源路由网络部分。通信系统300可以包括其他类型的网络，包括因特网协议(Internet Protocol，IP)网络。分组305到达源路由网络并且从源节点310被发送到目的节点315。在目的节点315，分组305可以退出源路由网络。源节点310和目的节点315可以被认为是源路由网络内的分组305的源节点和目的节点。分组305可以有其自身的源节点和目的节点，并且源节点310和目的节点315可以是通信系统300的源路由网络部分内的分组305的源节点和目的节点。可替换地，分组305实际上可以源自源节点310且结束于目的节点315。在这种情况下，在源节点310和目的节点315处可能没有箭头以指示分组305的入口和出口。

由于使用基于索引的源路由，源节点310指定分组305的数据路径，该路径包括中间节点316、中间节点317、中间节点318和中间节点319，例如，在该路径结束于目的节点315之前。在一个说明性示例中，源节点310可以利用路径确定引擎或表来确定到目的节点315的数据路径(或路径序列)。在SDN网络中，路径确定引擎或表可以将路径信息提供给SDN控制器，该SDN控制器可以将路径信息传送到源节点。

突出显示320提供分组305在离开源节点310并朝向中间节点316前进时的详细视图。分组305的突出显示320中的下一跳索引字段322可以保存指示分组305在中间节点316处跳的值。突出显示330提供分组305离开中间节点316时的详细视图。分组305的突出显示330中下一跳索引字段332可以保存指示分组305在中间节点317处的跳的值。突出显示340提供分组305离开中间节点317时的详细视图。分组305的突出显示340中下一跳索引字段342可以保存指示分组305在中间节点318处的跳的值。突出显示350提供在分组305离开中间节点318时的详细视图。分组305的突出显示350中下一跳索引字段352可以保存指示分组305在中间节点319处的跳的值。突出显示360提供在分组305离开中间节点319时的详细视图。分组305的突出显示360中下一跳索引字段362可以保存大于从源节点310到目的节点315的数据路径中的跳数的值。目的节点315在接收到分组305时可以检测跳索引362的值为6，其大于跳数。因此，目的节点315能够确定其是分组305的目的地(至少在通信系统300的源路由网络部分中)。

如前所述，验证和/或确认源节点和目的节点之间的数据路径可能是有好处的。通常，对分组流执行数据路径验证和/或确认。在源节点和目的节点之间验证数据路径的对称性(即，在前向路径(从源到目的)和反向路径(从目的到源)中的跳，这两种路径穿过相同的节点集合，但顺序相反)也是有好处的。

根据示例性实施例，告警标识或指示符被添加到用于满足路径确认请求的分组中。告警标识或指示符可以被添加到分组的分组报头部分。告警标识或指示符可以被添加到分组的分组报头部分的跳大小字段。或者，告警标识或指示符可以被添加到分组的分组报头部分的任何一个字段。或者，告警标识或指示符可作为单独字段被添加到分组的分组报头部分。本领域技术人员将理解，在一些情况下，可以设置正在通过网络发送的数据分组上的告警标识，使分组可以被用来处理路径确认请求。在这种情况下，通过确保选择正确的数据分组来确定路由。诸如数据分组长度之类的因素可能与数据分组的选择有关。接收双用途分组的节点可能需要修改它们处理分组的方式，并且可能也需要解决诸如延迟之类的问题。

根据示例性实施例，告警标识或指示符是具有第一值和第二值的二值(二进制)指示符，其中，第一值(或第二值)指示分组用于满足路径确认请求，第二值(或第一值)指示分组不用于满足路径确认请求。根据另一示例性实施例，告警标识或指示符是可以采用多于2个值的多比特指示符。在这种情况下，多比特告警标识或指示符可以与路径确认报头(以下详细讨论)结合使用以改善接收具有多比特告警标识或指示符的分组的节点执行的操作。此外，当与路径确认报头结合使用时，多比特告警标识或指示符甚至可以指定执行操作的节点类型或哪些节点类型执行哪种操作等。作为说明性示例，可以分配多个比特用作多比特指示符。多比特中的一个比特，例如第一比特，可以用作简单的告警，以使节点知道节点要检查分组。多个比特中的其他比特可以用于指示所需的操作。请注意，用作告警的比特可以总是被设置为开(或1)以进行分组确认，而其他比特可以被设置为开(或1)值以指示所需的操作。作为又一说明性示例，考虑包括8比特长的多比特告警标识的示例性分组：B1B2B384B5B6B7，其中，B1用作告警标识，B6指示需要的路径对称性。因此，比特可以被设置为10000100。中间节点可以忽略B6，但是当分组到达目的节点时，其检查B6，并且由于其被设置，目的节点简单地使跳序列反向，而不是生成其自己的反向路径。节点可以检查所请求操作的路径验证(Path Validation，PV)报头。作为另一说明性示例，B5可以向所有节点指示无操作(No Operation，No-op)。这种情况可以包括反向路径中的节点不需要执行任何操作的场景。

根据示例性实施例，将路径确认报头添加到用于满足路径确认请求的分组中。路径确认报头可以被添加到分组的非分组报头部分。路径确认报头可以跟随分组的分组报头部分。路径确认报头可以引导或跟随分组的有效载荷部分。路径确认报头可以包括由确认请求进行请求的信息类型的指示。路径确认报头可以包括过程的指示，例如动作类型和/或分组的数据路径中的节点要执行的操作。路径确认报头可以包括分组的数据路径中的节点要执行的指令。

图4示出了示例性确认请求分组400。确认请求分组400包括分组报头，该分组报头包括下一跳索引字段405、总跳数字段410、告警标识415和跳大小字段420。下一跳索引字段405、总跳数字段410、告警标识415和跳大小字段420共同形成确认请求分组400的分组报头。请注意，分组报头在格式上与图2的分组200的分组报头相似。确认请求分组400还包括N个跳字段(诸如跳1字段425、跳2字段427和跳N字段429)以及路径确认报头(PV报头)字段435。在一些实施例中，分组400还可以包括有效载荷字段。需要注意的是，N个跳字段包含与通过数据路径确认请求命令被确认的业务流的普通分组相同的跳。下一跳索引字段405可以存储用作分组400的下一跳指针的值。总跳数字段410可以存储指示分组400的总跳数的值。告警标识415可以用作指示符，其指示该分组400是确认请求分组。跳大小字段420可以存储指示每个单独跳大小的值。如图4所示，告警标识415是跳大小字段420的一部分。跳字段(诸如跳1字段425、跳2字段427和跳N字段429)可以存储指示分组400在它离开节点时采用的链路(或跳)的值。PV报头435可以包括分组400正在请求的信息类型、指令、操作等的指示。

PV报头435可以具有接收分组400的节点要执行的默认处理，其中，如果PV报头435没有明确地指定处理，则接收分组400的节点将执行默认处理。在这种情况下，PV标头435可以被说成是隐式地指定默认处理。作为说明性示例，如果PV标头435没有明确地指定处理，则无操作(NOOP)就是节点将执行的默认处理。PV报头435可以为接收分组400的所有节点指定相同的处理。换句话说，每个节点执行相同的处理。PV报头435可以为接收分组400的不同节点指定不同的处理。也即，根据在PV报头435中指定的内容，不同的节点可以执行不同的处理。

如上所述，分组400还可以包括可以用于存储分组400的数据和/或控制信息的有效载荷字段440。有效载荷字段440还可以存储节点在它们接收分组400以及执行如在PV报头字段435中所指定的过程(诸如指令、动作类型、操作等)的结果。在一些情况下，分组400可以不含有效载荷字段440。作为说明性示例，当接收分组400的节点将执行NOOP时，可能不需要有效载荷字段440。分组400可以用作连续性检查，即，例如检查在分组400中指定的路径是否上行并且支持业务。换句话说，分组400可以被加入到源路由网络中，并且当接收到响应时，在分组400中指定的路径被认为是上行并且可支持业务。

根据示例性实施例，告警标识是二值指示符。告警标识可以使用作为分组报头中的1比特指示符来实现。虽然在图4中所示的告警标识为分组报头跳大小字段420的一部分，但是告警标识可以是分组报头任何其他字段的一部分。或者，告警标识可以是分组报头中的单独字段。因此，告警标识作为跳大小字段一部分的讨论和图示不应被解释为限制示例性实施例的范围或精神。

图5示出了通信系统500，其突出显示确认请求分组的路径。响应于接收到的指定要被验证和/或确认的特定业务流的数据路径确认请求命令，确认请求分组505可以由源节点510加入到通信系统500中。从在数据路径确认请求命令中指定的业务流中，可为确认请求分组505确定跳序列，其与业务流的分组的跳序列相同。确认请求分组505可以被发往目的节点515。突出显示520示出当确认请求分组505被源节点510加入通信系统500时的详细视图。突出显示520可以包括添加了告警标识522和PV报头524的典型的基于索引的源路由分组字段(如图2中分组200的说明性结构)。

如前所述，当确认请求分组505遍历去往目的节点的路径上的节点时，其遍历的节点检测到告警标识522被设置。在检测到告警标识522被设置时，节点检查PV报头524以确定它们要执行的过程(诸如动作类型、指令、操作等)。在完成这些过程(诸如动作类型、指令、操作等)之后，节点将结果存储在确认请求分组505的有效载荷中。

目的节点515在接收到确认请求分组505(详细地示为突出显示530)时也执行例如动作类型、指令、操作等的过程，并将结果存储在有效载荷中。目的节点515还知道它是确认请求分组505的目的地，生成确认请求分组505的反向路径(在突出显示540的框542中示出了示例性反向路径)，并且重置存储在下一跳索引字段中的值。根据示例性实施例，通过反转存储在确认请求分组505中的链路(跳)的序列来生成反向路径。根据示例性实施例，目的节点515可以访问路径确定引擎(或表)以确定用于确认请求分组505的反向路径。在这种情况下，反向路径可以不同于将存储在确认请求分组505中的跳序列进行反转的结果。

为了清楚起见，与确认请求分组505相对应的确认请求分组可以被称为确认响应分组。确认响应分组可以与由目的节点515接收的确认请求分组505相同，除了新生成的反向路径和下一跳索引中的改变(以及一些潜在的总跳数和跳大小字段的改变，当反向路径不同于包括在确认请求分组505中的跳序列时)。目的节点515可以将确认响应分组(显示为突出显示540)发回到源节点505。由确认响应分组遍历的节点检查PV报头，以确定它们将要执行的过程，例如动作类型、指令、操作等。在完成这些过程(例如动作类型、指令、操作等)之后，节点将结果存储在确认响应分组的有效载荷中。根据示例性实施例，目的节点515包括确认响应分组中的指示，其指示中间节点不采取动作。在这种情况下，接收确认响应分组的中间节点根据包括在其中的路由信息简单地转发确认响应分组。

图6a示出了通信系统600，其突出显示确认请求分组的有效载荷，其中，当确认请求分组通过通信系统600时，反向路径和前向路径相同(但反向)。源节点将确认请求分组加入到通信系统600中，并且去往目的节点610。当确认请求分组加入到通信系统600中时，源节点605将过程，例如动作类型、指令、操作等(如在确认请求分组中的PV报头中指定的)完成的结果，加入到有效载荷中。作为说明性示例，考虑这样一种情况，其中例如动作类型、指令、操作等过程为用于节点将用于发送确认请求分组的链路插入有效载荷中的指令(如框620所示)。随着确认请求分组朝向目的节点610前进，每个节点将用于发送确认请求分组的链路插入到有效载荷中(示为框625、框630、框635和框640)。框645、框650、框655、框660和框665示出了在确认请求分组返回到源节点605时其有效载荷的内容。由于确认请求分组的反向路径和前向路径相同(但是反向)，所以确认请求分组的有效载荷包括确认请求分组遍历的链路的对称列表。

图6b示出了通信系统670，其突出显示确认请求分组的有效载荷，当确认请求分组通过通信系统670时，其反向路径不同于前向路径。确认请求分组由源节点675加入到通信系统670中，并且去往目的节点680。当确认请求分组加入到通信系统670中时，源节点675将过程，例如动作类型、指令、操作等(如在确认请求分组中的PV报头中所指定的)完成的结果加入有效载荷中。作为说明性示例，考虑这样一种情况，其中，例如动作类型、指令、操作等过程为用于节点将用于发送确认请求分组的链路插入有效载荷中的指令(如框682所示)。当确认请求分组朝向目的节点680前进时，每个节点将用于发送确认请求分组的链路插入到有效载荷中(示为框683、框684、框685和框686)。目的节点680可以不依赖于由确认请求分组提供的跳序列。替代地，目的节点680可针对返回到源节点675的返回路径中新的一组跳来查询控制器、路由查找表等。框687、框688、框689、框690、以及框691示出了在确认请求分组返回到源节点675时其有效载荷的内容。由于确认请求分组的反向路径和前向路径不同，所以确认请求分组的有效载荷包括确认请求分组遍历链路的非对称列表。

图7示出了在对称请求的情况下的示例性确认请求分组。图7中所示的确认请求分组表示单个确认请求分组的两个阶段。确认请求分组705表示确认请求分组的第一阶段，因为其遍历从源节点到目的节点的路径上的节点，确认响应分组710表示确认请求分组的第二阶段，因为其遍历从目的节点回到源节点的路径上的节点。除了与分组报头和跳字段中反向路径相关的信息之外，确认响应分组710可以具有与确认请求分组705相似的外观。

图8示出了在参与数据路径确认和验证的源节点中发生的示例性操作800的流程图。操作800可以指示在作为源节点参与数据路径确认和验证的源节点(例如源节点510、源节点605等)中发生的操作。

操作800可以开始于源节点接收数据路径确认请求(框805)。源节点可以从操作员出接收数据路径确认请求命令，该操作员正在使用源节点的命令行接口或软件定义网络控制器的管理控制台下发数据路径确认请求命令。数据路径确认请求命令可以用于验证与进入源路由域的源节点的业务流相关联的数据路径。数据路径确认请求命令可以指定关于业务流的信息(即，业务流信息)，这有助于识别业务流。例如，业务流信息可以以业务流标识的形式表示。

作为业务流信息的另一说明性示例，考虑其中，基于索引的源路由区域被常规IP网络包围的情况。在这种情况下，业务流可以包括具有目的地址x.y.z.w.的分组。当具有目的地址(x.y.z.w)的IP分组遇到基于索引的源路由网络的初始边缘时，对应的交换机可以基于其从SDN控制器接收的信息插入源路由报头和跳序列，然后将分组朝向基于索引的源路由网络的终止边缘发送。在终止边缘，终止源路由节点可以消除所有源路由报头和跳序列，从而允许正常的IP处理执行任何剩余路由以使分组达到目的地址。假设操作者希望验证基于索引的源路由网络中的业务流分组路径并要求每个节点识别出局链路，则初始边缘节点处的示例性命令可以表示为：

sourceRouteVerifyx.y.z.waction：recordoutboundLink.

在这样的示例性命令中，目的地址(x.y.z.w)可以用作业务流信息以识别分组流。

数据路径确认请求命令还可以指定节点应该执行的过程，例如动作类型、指令、操作等，并且将其结果插入到与数据路径确认请求命令相关联的确认请求分组的有效载荷中。

源节点可以生成确认请求分组(框810)。确认请求分组可以具有类似于图4所示的格式或先前讨论的其变化的格式。生成确认请求分组可以包括源节点根据业务流信息确定路由和路由信息并且在确认请求分组中生成(例如：放置信息)。作为说明性示例，源节点可以使用与业务流相关联的路径(由数据路径确认请求命令中指定的业务流信息标识)来确定路由和路由信息，并且将路由信息(例如：跳数、跳大小、跳等)插入确认请求分组中。源节点可以设置告警标识并且在确认请求分组的PV报头中包括例如动作类型、指令、操作等过程。

源节点可以处理确认请求分组(框815)。换句话说，源节点可以执行任何包括在确认请求分组的PV报头中的过程，诸如动作类型、指令、操作等，并将结果插入到确认请求分组的有效载荷中。源节点还可以更新确认请求分组的下一跳索引。源节点可以加入确认请求分组(框820)。源节点可以接收与确认请求分组相对应的确认响应分组(框825)。确认响应分组可以是已经由确认请求分组的目的节点修改的确认请求分组的版本，其可以包括用于回到源节点的确认响应分组的反向路径(以及任何相关联的路由信息改变)，还包括由确认请求分组遍历的节点形成的包括在有效载荷中的信息以及由确认响应分组遍历的节点形成的包括在有效载荷中的潜在信息。源节点可以处理确认响应分组(框830)。确认响应分组的处理可以包括处理有效载荷以分析由确认请求分组和/或确认响应分组遍历的节点插入的信息、验证数据路径、验证路径对称性等。

图9示出了在正在处理分组的节点中发生的示例性操作900的流程图。操作900可以指示在节点处理分组时发生在诸如中间节点或目的节点(例如目的节点515和610)中的操作。

操作900可以开始于节点接收分组(框905)。该分组可以是确认请求分组。如前所述，确认请求分组可以通过将告警标识设置为指定值来指示。节点可以检查确认请求分组的PV报头，执行在PV报头中指定的过程，例如动作类型、指令、操作等，并将结果保存到确认请求分组的有效载荷中(框910)。

节点可以执行检查以确定它是否为分组的最后一跳(框915)。作为说明性示例，节点可以核对分组中的下一跳索引和跳数值，并且如果下一跳索引大于跳数值，则节点可以确定它是分组的最后一跳。如果节点是分组的最后一跳，则节点可以识别用于确认请求分组的反向路径，并且重置下一跳索引(框920)，并在指定的链路上发送确认请求分组(框925)。如前所述，识别反向路径可以包括反转存储在确认请求分组中的跳或使用路径确定引擎或表来识别从确认请求分组的节点返回到源节点的路由。识别反向路径还可以包括节点生成用于反向路径的路由信息，诸如下一跳索引、跳数、跳大小、跳等。如果节点不是分组的最后一跳，则节点可以在指定的链路上发送分组(框925)。

图10示出了示例性第一通信设备1000。通信设备1000可以作为源节点的实现。通信设备1000可以用于实现本文所讨论的各种实施例。如图10所示，发送器1005用于发送分组、确认请求分组等。通信设备1000还包括用于接收分组、确认请求分组等的接收器1010。

请求处理单元1020用于接收数据路径确认请求。数据路径确认请求可以来自正在使用源节点的命令行界面或软件定义网络控制器的管理控制台的操作员下发的用于特定业务流的数据路径确认请求命令。请求处理单元1020用于处理数据路径确认请求。分组生成单元1022用于从数据路径确认请求生成确认请求分组。分组生成单元1022用于将告警标识设置为指定值，以指示该分组为确认请求分组。分组生成单元1022用于在PV报头中放置例如动作类型、指令、操作等的过程。分组生成单元1022用于在确认请求分组的剩余部分中放置值，诸如跳数、跳索引、跳、跳大小、有效载荷等。确认单元1024用于处理接收到的分组，诸如接收到的与由通信设备1000发送的确认请求分组相对应的确认响应分组。确认单元1024用于处理存储在所接收的确认响应分组的有效载荷中的信息，以验证和/或确认数据路径、验证数据路径对称性等。分组处理单元1026用于处理确认请求分组和确认响应分组。分组处理单元1026用于检查PV报头，执行在PV报头中指定的过程，例如动作类型、指令、操作等，并且将结果保存到分组的有效载荷中。分组处理单元1026用于更新诸如跳索引等的信息以执行源路由。存储器1030用于存储分组、数据路径确认请求、确认请求分组、接收到的确认请求分组、存储在有效载荷中的结果等。

通信设备1000的组件可以被实现为特定的硬件逻辑块。在替代方案中，通信设备1000的组件可以被实现为在处理器、控制器、专用集成电路等中执行的软件。在又一替代中，通信设备1000的组件可以实现为软件和/或硬件的组合。

作为示例，接收器1010和发送器1005可以被实现为特定的硬件块，而请求处理单元1020、分组生成单元1022、确认单元1024和分组处理单元1026可以是在微处理器(如处理器1015)中执行的软件模块或现场可编程逻辑阵列的定制电路或定制编译逻辑阵列。请求处理单元1020、分组生成单元1022、确认单元1024和分组处理单元1026可以是存储在存储器1030中的模块。

图11示出了示例性第二通信设备1100。通信设备1100可以作为源节点的实现。通信设备1100可以用于实现本文所讨论的各种实施例。如图11所示，发送器1105用于发送分组、确认请求分组等。通信设备1100还包括用于接收分组、确认请求分组等的接收器1110。

分组处理单元1120用于处理接收的分组。分组处理单元1120用于确定所接收的分组是否为确认请求分组。分组处理单元1120用于执行包含在确认请求分组的PV报头中的过程，例如动作类型、指令、操作等。分组处理单元1120用于在确认请求分组的有效载荷中存储执行过程的结果，例如动作类型、指令、操作等。分组处理单元1120用于确定所接收的分组是否发往通信设备1100。路径反向单元1122用于如果通信设备1100是确认请求分组的预期目的地，则反转存储在确认请求分组中的跳的顺序。路径反向单元1122用于：如果通信设备1100是确认请求分组的预期目的地，则使用路径确定引擎或表来识别用于确认请求分组返回其源节点的路由(此处称为确认响应分组)。跳重置单元1124用于：如果通信设备1100是确认请求分组的预期目的地，则重置确认请求分组中的下一跳索引。存储器1130用于存储分组、确认请求分组、接收到的确认请求分组，存储在有效载荷中的结果等。

通信设备1100的组件可以被实现为特定的硬件逻辑块。在替代方案中，通信设备1100的组件可以被实现为在处理器、控制器、专用集成电路等中执行的软件。在又一替代中，通信设备1100的组件可以实现为软件和/或硬件的组合。

作为示例，接收器1110和发送器1105可以被实现为特定的硬件块，而分组处理单元1120、路径反转单元1122和跳重置单元1124可以是在微处理器(如处理器1115)中执行的软件模块或者定制电路或现场可编程逻辑阵列的定制编译逻辑阵列。分组处理单元1120、路径反向单元1122和跳重置单元1124可以是存储在存储器1130中的模块。

虽然已经详细描述了本公开及其优点，但是应当理解的是，在不偏离所附权利要求所限定的本公开的精神和范围的情况下，可以做出多种改变、替换和变更。

Claims (34)

1.一种用于操作源节点的方法，所述方法包括：

所述源节点接收数据路径确认请求命令，所述数据路径确认请求命令用于请求确认与标识于所述数据路径确认请求命令中的业务流相关联的路径；

所述源节点根据被确认的所述路径，确定第一跳序列，其中所述第一跳序列和与非确认请求分组相关联的第二跳序列相同，所述非确认请求分组与被确认的所述路径相关联；

所述源节点根据所述数据路径确认请求命令，生成确认请求分组，所述确认请求分组包括与所述第一跳序列相关联的路由信息、设置为指定值的告警标识以及路径确认报头，所述路径确认报头指定由接收所述确认请求分组的节点执行的处理；以及

所述源节点根据所述路由信息发送所述确认请求分组。

2.根据权利要求1所述的方法，其中，所述路径确认报头用于指定由接收所述确认请求分组的所有节点执行的相同处理。

3.根据权利要求1所述的方法，其中，隐式地指定所述处理。

4.根据权利要求1所述的方法，其中，所述生成的确认请求分组还包括有效载荷字段。

5.根据权利要求1所述的方法，其中，所述数据路径确认请求命令还包括所述指定的处理。

6.根据权利要求1所述的方法，还包括：所述源节点从所述确认请求分组的目的节点接收与所述确认请求分组相对应的确认响应分组。

7.根据权利要求6所述的方法，其中，所述告警标识位于所述确认响应分组的分组报头中。

8.根据权利要求6所述的方法，其中，所述确认响应分组的有效载荷包括由接收所述确认请求分组和所述确认响应分组中的至少一个的节点执行的所述指定的处理的结果。

9.根据权利要求8所述的方法，还包括处理所述结果以验证所述路径。

10.如权利要求6所述的方法，其中，所述确认响应分组包括与第三跳序列相关联的路由信息，所述第三跳序列指定所述目的节点和所述源节点之间的所述确认响应分组的反向路径。

11.根据权利要求1所述的方法，其中，在所述源节点的命令行接口和软件定义网络控制器的管理控制台之一上接收所述数据路径确认请求命令。

12.根据权利要求1所述的方法，其中，所述路径确认报头包括动作类型、指令和操作中的至少一个。

13.根据权利要求1所述的方法，其中，确定所述第一跳序列包括复制所述第二跳序列。

14.根据权利要求1所述的方法，其中，所述告警标识位于所述确认请求分组的分组报头中。

15.根据权利要求14所述的方法，其中，所述分组报头包括至少一个现有字段，并且其中所述告警标识位于所述分组报头的现有字段中。

16.根据权利要求15所述的方法，其中，所述现有字段是跳大小字段。

17.根据权利要求14所述的方法，其中，所述告警标识位于所述分组报头的告警标识字段中。

18.根据权利要求1所述的方法，其中，所述告警标识是二值指示符。

19.根据权利要求1所述的方法，其中，所述告警标识是多比特指示符。

20.一种用于操作节点的方法，所述方法包括：

所述节点接收确认请求分组，所述确认请求分组包括：设置为指定值的告警标识、用于所述确认请求分组的跳序列、指定所述跳序列中的当前跳的跳索引、所述跳序列中的跳数以及路径确认报头，所述路径确认报头指定由接收所述确认请求分组的节点执行的处理；以及

所述节点执行处理以根据所述路径确认报头产生结果。

21.根据权利要求20所述的方法，还包括所述节点将所述结果存储在所述确认请求分组的有效载荷中。

22.根据权利要求20所述的方法，还包括：

在确定所述节点是所述确认请求分组的目的节点时，识别所述确认请求分组的反向路径；以及

当所述节点是所述确认请求分组的目的节点时，根据所述反向路径将所述确认请求分组转发给下一个节点。

23.根据权利要求22所述的方法，其中，转发所述确认请求分组包括根据所述反向路径通过链路发送所述确认请求分组。

24.根据权利要求22所述的方法，其中，确定所述节点是所述目的节点包括确定所述跳索引大于所述跳数。

25.根据权利要求22所述的方法，还包括：

当所述节点不是所述确认请求分组的目的节点时，根据所述跳序列将所述确认请求分组转发到下一个节点。

26.一种源节点，所述源节点包括：

接收器，用于接收数据路径确认请求命令，所述数据路径确认请求命令用于请求确认与标识于所述数据路径确认请求命令中的业务流相关联的路径；

可操作地耦合到所述接收器的处理器，所述处理器用于根据被确认的所述路径，确定第一跳序列，其中所述第一跳序列和与非确认请求分组相关联的第二跳序列相同，所述非确认请求分组与被确认的所述路径相关联；并且根据所述数据路径确认请求命令，生成确认请求分组，所述确认请求分组包括与所述第一跳序列相关联的路由信息、设置为指定值的告警标识以及路径确认报头，所述路径确认报头指定由接收所述确认请求分组的节点执行的处理；以及

可操作地耦合到所述处理器的发送器，所述发送器用于根据所述路由信息来发送所述确认请求分组。

27.根据权利要求26所述的源节点，其中，所述处理器用于生成具有有效载荷字段的所述确认请求分组。

28.根据权利要求26所述的源节点，其中，所述接收器用于从所述源节点的命令行接口和软件定义网络控制器的管理控制台之一接收所述数据路径确认请求命令。

29.根据权利要求26所述的源节点，其中，所述接收器用于从所述确认请求分组的目的节点接收对应于所述确认请求分组的确认响应分组。

30.根据权利要求29所述的源节点，其中，所述确认响应分组包括指定所述目的节点和所述源节点之间的所述确认响应分组的第二路径的第三跳序列。

31.根据权利要求29所述的源节点，其中，所述确认响应分组的有效载荷包括由接收所述确认请求分组和所述确认响应分组中的至少一个的节点执行的处理的结果，并且其中所述处理器用于处理所述结果以确认用于所述确认请求分组的所述第一跳序列。

32.一种节点，所述节点包括：

接收器，所述接收器用于接收包括确认请求分组，所述确认请求分组包括：设置为指定值的告警标识、用于所述确认请求分组的跳序列、以及路径确认报头，所述路径确认报头指定由接收所述确认请求分组的节点执行的处理；以及

可操作地耦合到所述接收器处理器，所述处理器用于根据所述路径确认报头执行过程以产生结果。

33.根据权利要求32所述的节点，其中，所述处理器用于将所述结果存储在所述确认请求分组的有效载荷中。

34.根据权利要求32所述的节点，其中，所述处理器用于确定所述节点是否为所述确认请求分组的目的节点，当所述节点是所述确认请求分组的目的节点时，识别所述确认请求分组的反向路径，以及当所述节点是所述确认请求分组的目的节点时，根据所述反向路径将所述确认请求分组转发到下一个节点。