网络环境中的触发式带内操作、管理和维护的制作方法

相关申请的交叉引用

本申请根据35u.s.c.§119(e)要求于2015年10月20日递交的、题为“triggeredin-bandoperations,administration,andmaintenanceinanetworkenvironment(网络环境中的触发式带内操作、管理和维护)”的美国临时专利申请no.62/244,095的优先权，其全部内容通过引用被完整结合于此。

本公开总体涉及网络领域，并且更具体地，涉及网络环境中的触发式带内操作、管理和维护。

背景技术：

随着网络持续不断地大幅增长与其规模的持续扩大，需对大规模执行操作、管理和维护(oam)、遥测、和服务水平协议(sla)验证和报告的方式的界限进行测试与延伸。在计算机网络中，oam包括被设计用于监视和管理网络操作的过程、功能、活动、工具等，以便检测网络故障、隔离所述故障以及测量网络性能。带内oam可作为“永开启”服务被使用，该服务可将转发路径信息或服务路径信息以及其他信息和/或统计信息添加至网络流量。带内oam是还可包含被动oam和/或网络遥测(int)的术语。所述信息可以是关于网络中每个分组所经历的状态或转发行为的非常详细的信息。如果针对网络中每个分组对于所有特征都启用带内oam，则可能会创建大量数据。

带内oam可以针对被应用该带内oam的每个客户分组创建记录或数据报。也就是说，在所有流量都使用带内oam的情况下，可以针对每个分组创建oam数据记录。

附图说明

为了提供对本公开及其特征和优点的更完整理解，对结合附图所做的以下描述进行参考，其中，相似标号表示相似部分，其中：

图1是根据本公开的至少一个实施例示出的网络环境中的具有触发式带内操作、管理和维护(oam)的通信系统中的示例场景的简化框图；

图2是根据本公开的至少一个实施例示出的具有触发式带内oam的通信系统中的另一示例场景的简化框图；以及

图3是根据本公开的至少一个实施例示出的具有触发式带内oam的通信系统中的又一示例场景的简化框图。

图4是根据本公开的实施例的用于触发网络环境中的带内操作、管理和维护的过程流程图。

图5是根据本公开的实施例的用于利用带内操作、管理和维护(ioam)信息来扩充分组的过程流程图。

具体实施方式

实施例的各个方面涉及：接收指示网络中的问题的第一通知；在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能；评估包括由数据收集功能扩充的数据的后续分组；以及基于被扩充至后续分组的数据确定网络中的问题。

在一些实施例中，第一通知指示第一分组未通过服务平面验证，并且其中，数据收集功能包括应用于后续第二分组的分组跟踪功能，数据收集功能用包括对应于第一分组的源和目的地信息的源和目的地信息的数据来扩充第二分组。

一些实施例还可包括：接收指示第二分组未通过网络中的服务平面验证的第二通知，其中，第二通知包括与第二分组遍历网络中的一个或多个节点中的至少一者有关的分组跟踪信息。

在一些实施例中，分组跟踪信息包括导致第二分组未能通过服务平面验证的故障状况。

一些实施例可以包括识别第一分组未通过服务平面验证的原因，该识别是基于包括在与第二分组相关联的分组跟踪信息中的故障状况进行的。

在一些实施例中，第一通知是从网络中的节点或从网络外部的源接收的。

在一些实施例中，节点包括包含带内操作、管理、和维护(oam)节点的服务节点。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括使数据被扩充至后续分组的子集，并且其中，评估包括由数据收集功能扩充的数据的后续分组包括针对所述数据来评估分组的子集。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括触发数据收集功能用关于节点或网络路径的元数据来扩充携带数据流量的分组。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括对包含标记有带内操作、管理和维护(ioam)标签的测探数据的后续分组触发数据收集功能。

在一些实施例中，ioam标签是使用ipv6或vxlan-gpe报头中的一者进行传输的。

在一些实施例中，ioam标签包括延迟相关数据、分组丢失数据、遥测数据、分组路由信息、服务功能信息、或带宽相关数据中的一者或多者。

在一些实施例中，第一通知指示等于或高于阈值的分组丢失，该等于或高于阈值的分组丢失触发ioam监视。

在一些实施例中，第一通知指示等于或高于阈值的抖动率，该等于或高于阈值的抖动率触发ioam监视。

一种包括硬件处理器的网络元件，该硬件处理器被配置为：接收指示网络中的问题的第一通知；在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能；评估包括由数据收集功能扩充的数据的后续分组；以及基于被扩充至后续分组的数据确定网络中的问题。

在一些实施例中，第一通知指示第一分组未通过服务平面验证，并且其中，数据收集功能包括应用于后续第二分组的分组跟踪功能，数据收集功能用包括对应于第一分组的源和目的地信息的源和目的地信息的数据来扩充第二分组。

在一些实施例中，网络元件可被配置为接收指示第二分组未通过网络中的服务平面验证的第二通知，其中，第二通知包括与第二分组遍历网络中的一个或多个节点中的至少一者有关的分组跟踪信息。

在一些实施例中，分组跟踪信息包括导致第二分组未能通过服务平面验证的故障状况。

在一些实施例中，网络元件可被配置为识别第一分组未通过服务平面验证的原因，该识别是基于包括在与第二分组相关联的分组跟踪信息中的故障状况进行的。

在一些实施例中，第一通知是从网络中的节点或从网络外部的源接收的。

在一些实施例中，服务节点包括包含带内操作、管理、和维护(oam)节点。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括使数据被扩充至后续分组的子集，并且其中，评估包括由数据收集功能扩充的数据的后续分组包括针对所述数据来评估分组的子集。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括触发数据收集功能以用关于节点或网络路径的元数据来扩充携带数据流量的分组。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括对包含标记有带内操作、管理和维护(ioam)标签的测探数据的后续分组触发数据收集功能。

实施例的各个方面涉及一种包括网络元件的系统，该网络元件被配置为：从网络位置接收分组并且将该分组发送到另一网络位置，该网络元件被配置为识别分组进行网络遍历中的错误；以及向网络控制器或入口节点或可触发ioam监视的另一节点发送关于该错误的通知。网络控制器可以被配置为从网络元件接收关于错误的通知；以及指示网络的一个或多个网络元件激活数据收集功能。

在一些实施例中，网络控制器被配置为针对将遍历网络的分组来配置带内操作、管理和维护(ioam)路径跟踪。

在一些实施例中，网络元件包括被配置为检查到达网络元件的分组的服务链验证者(scv)网络元件；针对该分组验证一个或多个策略；以及通知网络控制器关于未通过的策略。

在一些实施例中，网络元件被配置为用与一个或多个分组专用或网络专用的策略有关的带内操作、管理和维护(ioam)信息来扩充携带数据流量的分组。

在一些实施例中，网络元件被配置为从网络位置接收包括带内操作、管理和维护(ioam)信息的分组；基于该ioam信息确定该分组的路径跟踪；以及向网络控制器转发具有来自分组的路径跟踪信息的通知。

实施例的各方面涉及一种具有指令的非暂态计算机可读介质，这些指令在被运行时可进行操作用以：接收指示网络中的问题的第一通知；在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能；评估包括由数据收集功能扩充的数据的后续分组；以及基于被扩充至后续分组的数据确定网络中的问题。

在一些实施例中，第一通知指示第一分组未通过服务平面验证，并且其中，数据收集功能包括应用于后续第二分组的分组跟踪功能，数据收集功能用包括对应于第一分组的源和目的地信息的源和目的地信息的数据来扩充第二分组。

一些实施例还可包括：接收指示第二分组未通过网络中的服务平面验证的第二通知，其中，第二通知包括与第二分组遍历网络中的一个或多个节点中的至少一者有关的分组跟踪信息。

在一些实施例中，分组跟踪信息包括导致第二分组未能通过服务平面验证的故障状况。

一些实施例可以包括识别第一分组未通过服务平面验证的原因，该识别是基于包括在与第二分组相关联的分组跟踪信息中的故障状况进行的。

在一些实施例中，第一通知是从网络中的节点或从网络外部的源接收的。

在一些实施例中，节点包括包含带内操作、管理、和维护(oam)节点的服务节点。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括使数据被扩充至后续分组的子集，并且其中，评估包括由数据收集功能扩充的数据的后续分组包括针对所述数据评估分组的子集。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括触发数据收集功能以用关于节点或网络路径的元数据来扩充携带数据流量的分组。

在一些实施例中，在网络中的一个或多个节点上针对遍历该一个或多个节点的后续分组触发数据收集功能包括对包含标记有带内操作、管理和维护(ioam)标签的测探数据的后续分组触发数据收集功能。

在一些实施例中，ioam标签是使用ipv6或vxlan-gpe报头中的一者进行传输的。

在一些实施例中，ioam标签包括延迟相关数据、分组丢失数据、遥测数据、分组路由信息、服务功能信息、或带宽相关数据中的一者或多者。

在一些实施例中，第一通知指示等于或高于阈值的分组丢失，该等于或高于阈值的分组丢失触发ioam监视。

在一些实施例中，第一通知指示等于或高于阈值的抖动率，该等于或高于阈值的抖动率触发ioam监视。

为了说明本文所公开的带内操作、管理和维护(oam)系统的某些示例技术，重要的是理解可遍历网络进行的通信和用于实现这种通信的协议。以下基本信息可以被视为可恰当解释本公开的基础。

带内oam(ioam)对流量是如何转发的进行记录。为了实现这点，可以使用例如互联网协议版本6(ipv6)中可用的扩展报头、网络服务报头、分段路由、vxlan-gpe、mpls等来将诸如元数据或其他关联数据之类的信息直接插入网络流量中。这些信息可用于故障排除、规划、和路径或服务链验证，并可被插入到任何网络流量中，而不仅仅只是探测流量。信息可以在选定的节点处被插入并从出口设备进行撷取。信息是广泛分布的路径和节点或服务数据。信息的示例可以包括但不限于入口或出口接口标识符、时间戳、节点或服务标识符、描述服务或网络元件的秘密共享、序号、通用应用元数据、cpu利用率、和/或接口统计信息(例如，下降百分比、利用率等)。

在一个场景中，带内oam可以用于路径或服务链验证。该验证可以证明某些流量(例如，与由所使用的源ip地址、目的地ip地址、端口、和协议识别的应用相关联的流量)遍历特定的流量链或路径。在另一示例场景中，带内oam可用于进行流量通过网络的跟踪并检测有问题的路径。而且，应用特定的分组也可以被跟踪。应用特定的信息可在每个节点处被包括在分组中。

如果ioam“永开启”并且针对网络中的每一分组针对所有特征都要被启用，则生成大量数据的可能性是非常高的。并非对所有流量都要“永开启”所有的oam数据生成，通过在需要时启用ioam提高了ioam的效率，在这种情况下，能以最少量的开销来提供最大量的可用网络洞察。

上述由ioam针对所有流量创建的可操作数据的总量是一个所关心的方面。另一关心方面可包括ioam的使用会导致转发元件上成本的提高。例如，ioam的重度使用或“永开启”使用可导致转发元件的cpu负载非常高(因为数据的处理与插入不是无偿的，特别是在不在基于软件的转发器上进行数据的处理和插入时)或性能的下降。另外，并非所有的带内oam功能都具有相同的特性，例如，由于服务/路径验证需要对每个分组进行读-计算-写操作，因此相比例如在仅嵌入节点id时对流量的影响是不同的。

类似地，时间戳数据的添加(取决于时钟查找的效率)可能比添加入口或出口链接等数据的代价更大，所有的这些都使得人们并不希望所有ioam功能在所有时刻都处于被开启状态。要考虑的另一“问题”是所收集的元数据的大小。添加的元数据量越大，需要的开销就越多。这意味着如果在网络中使用ioam，则应用的有效路径mtu(最大传输单元)可能会更少。

触发式oam可以在若干实例中使用。通常，所使用的是对失败进行信号告知的传统带外oam。一些示例包括接入点控制协议(ancp)oam，用于触发本地环路上异步传输模式(atm)(f4/f5)环回信元的生成。此外，多协议标签交换(mpls)oam或网络虚拟化覆盖(nvo3)oam可作为保护式触发被使用。在另一示例中，y.1731/以太网连接故障管理(cfm)(802.1ag)oam部署也可以采用触发式oam。

y.1731的示例包括警报指示信号(ais)和远程故障指示(rdi)警报之类警报。这些触发式警报指示带外oam的使用，而非触发式带内oam。此外，这些警报元件是在运输层进行操作的，而不是在服务平面上操作的。

本文描述的实施例可以解决与带内oam相关的前述问题(其他问题)。本文公开的实施例提供了一种具有触发式带内oam能力的通信系统，这种系统可根据需要来动态地创建详细信息。通信系统可以包括多个节点，这些节点可以由在网络环境中通传的分组进行遍历。通信系统还可以包括与多个节点进行通信的控制器。在具有触发式带内oam功能的通信系统中创建的详细信息可在指示故障或提示潜在问题的情况下被生成。本文公开的用于针对互联网协议(ip)和覆盖技术(vxlan-gpe、sh、mpls等)的触发式带内oam的实施例在网络的服务路径上进行操作并且使用户的注意力集中在对实际的网络行为的分析上。通信系统的第一实施例提供了在外部事件或带内oam自身情况下触发的选择性多级带内oam。通信系统的第二实施例提供了(可以是单级的)带内探测式的带内触发。通信系统的第三实施例提供了带内oam采样。

本文公开的实施例提供了若干优点。首先，本文公开的实施例针对网络地址转换提供了高可扩展性和优化。本文公开的实施例可以减少由带内oam生成的数据量，并聚焦于针对用户(例如，网络运营商或管理员)感兴趣的信息所创建的数据。本文公开的实施例还就数据平面以及后处理分析方面实现了相应扩展。此外，实施例对于真实数据是真正带内的，而不使用发送错误消息或f4/f5报警的互联网控制消息协议(icmp)。例如，触发式带内oam不仅仅用于警报信号传递，还可以以触发的方式用于性能度量。此外，实施例涉及服务路径层面的触发式oam，其有效地创建了触发式服务遥测。此外，本文公开的实施例提供了灵活性并可提高仪器和遥测的信噪比。

第一实施例提供了一种具有多级触发式oam的通信系统，其中，带内oam的一个或多个数据收集能力是基于触发被启用的。触发的数据源可以是带内oam本身，也可以是其他外部事件。在示例场景中，网络异常可以被网络节点检测到。在检测到异常后，可以针对特定的一组流来启用特定的一组带内oam功能，以提供进一步的洞察。在一些实施例中，检测到异常的网络节点可以直接向一组入口节点发送触发，或者可以将该异常报告给控制器，控制器随后决定哪些ioam功能应该在哪些网络节点上被启用。事件与要被触发的特定ioam数据收集之间的关联可以由语义推理器来驱动，其中，所述语义推理器是由触发应用所知的网络模型驱动的。

在一些实施例中，触发可以以不同方式被通传。例如，检测到异常的节点可以发送触发以使之在诸如服务路径之类的通信路径内转发，从而使所述异常根据特定上下文(即，服务链的环境情况、检测到异常的节点、数据分组的内容等)被解释。该节点还可以将触发发送到预定义的汇聚点、代理点等。在任何情况下，触发的接收器都可以激活ioam数据收集。

现提供具有多级触发式带内oam的通信系统的示例场景。用户(例如，网络运营商或管理员等)可以使用带内oam来验证服务a、b和c的服务链的正确运作。例如，针对ipv6的ioam在数据分组中携带中转证明(proof-of-transit)数据。服务节点(例如，服务节点c)可以充当验证者。如果服务节点c检测到策略外分组，用户可能就会想知道为什么分组未通过路径/服务验证。例如，分组可能错过了特定的服务和/或节点。ioam中的中转证明数据可指示服务链没有进行正确遍历，但不能识别发生故障的位置。

多级触发式带内oam可以实现对系统中发生故障的位置的识别。首先，诸如服务节点c之类的验证服务节点检测到特定分组x的故障，并将该故障报告给控制器。控制器针对服务链上的与分组x具有相同源和目的地的所有分组触发(例如，启用、促进、开启、启动等)带内oam流跟踪。在至少一些实施例中，触发可以作为netconf通知被执行或者也可以是netflow/ipfix记录、kafka消息缓存代理(broker)客户端、google协议缓冲区等。当带内oam流跟踪被触发时，服务节点c报告每个具有与分组x相同的源和目的地的分组的详细路径信息。这被称为“多级”，其中，(例如用户)所选的要求得以遵循，并且不同的带内oam功能被启用或禁用。

当下一次验证失败时，控制器不仅接收到分组未通过服务链验证的通知，而且还接收到详细的流跟踪信息。例如，假设跟踪表明分组x访问了服务节点a、z和c，但没有访问服务节点b。有了这些信息，用户现在可以专注于对服务节点b的调试。

作为多级ioam的一个示例可以包括：

-级别0：首先，不涉及ioam；可包括虽检测到网络问题但还达不到可受益于ioam监视的情况；

-级别1：活跃oam(例如，ping)的失败触发利用粗采样和序号进行的ioam。

-级别2：语义推理器不检测序号上的异常，即使语义推理器应该这样做：可以触发序号的细粒度采样。丢失/重排序可被检测到。

-级别3：触发对似乎会经历偶尔发生丢失的分组进行详细跟踪(节点和时间戳记录)-以便识别出问题根源的节点。

每个级别都可以自动激活。

图1-图3根据至少一个实施例示出了网络环境中的具有带内oam的示例通信系统。图1示出了网络100中的带内oam的正常操作。控制器102在服务节点a104、b106和c110上配置服务链/路径验证(scv)。服务节点c110可以充当验证者。当分组遍历服务链114时，服务节点c110提供连续监视并检查分组是否已经正确地遍历服务链。网络100还包括节点z108。每个节点(或网络元件)可以经由通信路径(例如，通信路径112)被耦合。

图2示出了在通信系统200中发生的异常/失常以及使用多级触发式带内oam来识别关于所述异常/失常的相关信息的示例场景。在图2中，分组x未通过服务链验证(即对分组x的验证失败)。验证者(例如，本示例中的服务节点c110)向控制器102发送触发/通知(例如，netconf通知)与关于失败的信息(即，关于未通过的分组x的细节)。该通知的接收可使控制器配置附加带内oam功能。在图2的示例中，要被配置的附加带内oam功能是针对看起来像分组x的分组的路径跟踪。在一个示例中，路径跟踪可以包括针对例如具有与分组x相同的源和目的地信息(例如，网络地址、端口、协议)的分组记录节点和进入/外出接口信息。

图3示出了在通信系统中配置附加带内oam功能之后再次发生异常/失常的示例场景300。在图3的示例中，在发生异常/失常和附加带内oam功能的动态配置之后，可针对与分组x具有相同源和目的地的后续分组生成详细信息。在一个示例中，该详细信息可因在通信系统100的一个或多个节点中进行的路径跟踪的动态配置而被生成。如图3所示，分组“x+1”经由服务节点a104、节点z106和服务节点c110并绕过服务节点b106来遍历通信系统。分组x+1到达服务节点c110并且未通过服务链验证。但是，由于路径跟踪的配置，分组x+l包含ioam6路径跟踪信息。控制器(继而用户)可知晓scv失败可能是由于分组绕过服务节点b106而引起的。

在触发式带内oam的另一示例中，用户在访问实时网络应用时对抖动进行观察。用户可以通过门户来登录，以便进行所述观察。抖动可转换为用于针对特定用户和应用触发带内oam而进行评估的事件。该事件评估可致使触发带内oam功能来收集时间戳和路径分组计数器，以便识别问题的原因。所收集的数据可以给出引起网络中延迟、分组重排序和/或分组丢失的点的详细信息。

基于网络状况，某些带内oam能力被启用或禁用。这允许所收集的操作数据集中于基于特定实现方式、偏好和/或需求所期望或需要的特定数据。任何没有用途的数据可以通过不被生成或收集来避免。这样可使数据创建过程和数据后处理期间的性能受益。这也促使对可由于更高级别的编程网络调试而立即采取纠正措施的应用的使用。

第二实施例提供了一种具有带内触发式探测(probing)的通信系统。通过依靠用带内oam标记的探测数据可减少所创建的oam信息的总量。这是单级触发式带内oam。

为了调试或分析某些网络场景，用户可能希望向网络发送特定的探测数据。这种数据不同于ping或跟踪数据，至少部分是因为探测数据可以类似于正常的应用数据。这可确保网络以与常规流量相同的方式来处理和转发探测数据。

在至少一个实施例中，带内oam可被配置为使带内oam信息仅被添加至探测数据。目前可使用特定的探测数据来确定网络的健康状况。通过带内触发式探测所提供的附加信息可有助于对特定故障及其原因的识别。

在至少一个实施例中，取代使用类似于网络数据的探测分组，真实的网络分组可被使用。例如，我们可以在入口(无论哪种粒度)处配置分类器来专注于特定的流(例如，铂金服务、风险/额外安全检查所需的流等)，并在入口处将这些分组标记在ioam报头中。接着，下游节点可基于分组中携带的元数据(标签)以触发式ioam方式对报头执行操作。带内oam的带内触发的另一示例是设置在分类器处的特定流量模式或标志。

第三实施例提供了一种具有使用顺序和/或时间触发的采样oam的通信系统。采样带内oam数据可以减少呈现给分析系统的数据量。可通过使用采样减少数据量来增加可扩展性。在至少一个实施例中，(1)仅每第n个分组包括所添加的带内oam信息，或者(2)在出口节点处仅分析来自每第n个分组的信息。此外，每第n个分组的采样可以通过分组着色(例如，通过使用访问控制列表(acl))进行源控制或基于本地资源阈值(例如，缓冲、带宽等)由网络元件控制。

采样率和算法的其他示例可以根据所触发的信息进行调整。例如，如果观察到网络中的分组丢失，则可打开ioam以向分组添加序号来对分组丢失量进行检测。如果采样过于粗糙，则该采样可能无法正确示出分组丢失问题(例如，如果每第10个分组出现丢失，但采样仅对每第1000个分组进行查看，则就有可能无法检测到丢失)。ioam可被触发来对采样进行缩放，以便更好地检测分组丢失。

在至少一个实施例中，“n”可以是函数而不是固定值。例如，采样率可以是关于流长度的函数：流持续时间越长，标记有带内oam信息的分组越少。在其他实施方式中，采样率可以是时间触发的函数。采样率可以基于触发(例如，流长度阈值)进行调整。

本文描述的几个实施例(例如，由外部事件、带内探测、带内采样触发的多级带内oam)以触发的方式提供了对可操作元数据的创建。对于服务事件，真正的带内oam被触发会使信噪比提高。带内oam在服务路径上进行操作，并且可根据某些条件或警报被启用。在至少一个实施例中，警报可以是带内的(例如，信号/标志、特定流量模式)。触发的数据源可以是带内oam本身，也可以是其他外部事件。此外，分组着色可以是控制采样的动作。最后，本文描述的几个实施例的任何合适的组合可被提供来(例如在状况指示网络故障或提示潜在问题时)动态地创建详细的信息。

图4是根据本公开的实施例的用于触发网络环境中的带内操作、管理和维护的过程流程图400。控制器可以在网络中的一个或多个服务节点上配置带内oam服务链验证。分组遍历该服务链。在一些实施例中，节点可以充当检查分组是否已对服务链进行了正确遍历的服务链验证者(scv)。

网络元件(例如，scv)可以确定网络中的问题(402)。例如，网络元件可以确定服务功能未被应用于分组、分组未通过服务链校验或验证、网络异常、或其他问题。触发的数据源可以是带内oam本身，也可以是其他外部事件。

网络元件可以在网络的其他节点中触发带内oam数据收集功能(404)。在检测到异常情况后，将针对一组特定流启用一组特定的带内oam功能，以提供进一步的洞察。通常情况下，检测到异常的节点直接向一组入口节点发送触发，或者只是向控制器报告异常情况，然后控制器会决定哪些ioam功能应在哪些网络节点上被启用。事件与要被触发的特定ioam数据收集之间的关联可以由语义推理器来驱动，其中，语义推理器是由触发应用所知的网络模型驱动的。

网络元件可以从网络位置接收另一分组。网络元件可以确定该分组是否仍反映之前检测到的网络异常(406)。该分组可以包括与其所遍历的节点有关的附加信息(例如，ioam信息)以及其他网络信息。

网络元件可基于来自第二分组的ioam信息来确定网络问题或异常(408)。在一个示例中，如果第二分组未通过验证，则在下一次验证失败时，网络元件可以向控制器提供关于分组未通过服务链验证的通知，并且还接收详细的流跟踪信息。在路径验证场景中，假设跟踪示出分组只访问了节点a和节点c但没有访问节点b，则网络元件可识别出在节点b处的问题。网络元件可以将该问题报告给操作者，操作者现在可特别关注对节点b的调试。

图5是根据本公开的实施例的用于利用带内操作、管理和维护(ioam)信息来扩充分组的过程流程图500。诸如网络节点之类的网络元件可以接收用以激活数据收集功能(例如，ioam数据收集功能)的指令(502)。网络元件可以从网络位置接收数据分组(504)。网络元件可以用ioam信息(例如，关于节点、网络、服务功能、策略、或其他网络信息的信息)来扩充数据分组(506)。接着，网络元件可以将数据分组发送到网络中的下一跳位置(508)。

变形和实现

在本公开的上下文中，本文所指的网络表示用于接收和发送通过网络地址转换系统传播的信息的分组的互连通信路径的一系列点、节点、或网络元件。网络提供源、目的地、和中间节点之间的通信接口，并且可以是任何局域网(lan)、无线局域网(wlan)、虚拟专用网(vpn)或根据网络拓扑促进网络环境中的通信的任意其他适合的架构或系统。网络可包括通过通信介质耦合到彼此(并且彼此进行通信)的任何数目的硬件和/或软件元件。

网络环境中的通信在本文被称为“网络流量”或“流量”(可包括分组)。分组是格式化的数据单元，并且可以包含控制信息(例如，源和目的地地址等)和数据(也被称为有效载荷)。网络流量可以根据任何合适的通信消息协议来发送和接收。合适的通信消息协议可以包括诸如开放系统互连(osi)模型之类的多层方案或其任何衍生或变体(例如，传输控制协议/ip(tcp/ip)、用户数据报协议/ip(udp/ip))等)。本文使用的术语“数据”是指任何类型的二进制、数字、语音、视频、文本、或脚本数据，或任何类型的源或目标代码，或可从电子设备和/或网络的一点被通传至另一点的任何适当格式的任何其他合适的信息。此外，消息、请求、响应、回复、查询等都是网络流量的形式，因此可以包括分组。

本文描述的通信系统的节点、服务节点和控制器可以是网络环境中的网络元件。如本文所使用的，术语“网络元件”意味着包括路由器、交换机、网关、桥接器、负载平衡器、服务设备、防火墙、服务器、处理器、模块(其中任何一者可以物理地或虚拟地在物理硬件上实现)或可操作以在网络环境中交换信息的任何其他合适的设备、组件、元件、专有设备或对象。网络元件可包括便于进行其操作的任何合适的硬件、软件、组件、模块、接口或对象。这可包括允许数据或信息的有效交换的合适的算法和通信协议。

在至少一个示例实施方式中，具有本文描述的触发式带内oam能力的网络元件包括实现(或促进)如本文所概述的活动的逻辑。注意，在至少一个示例中，这些元件中的每一者可具有内部结构(例如，处理器、存储器元件、网络接口卡等)以便于进行本文描述的一些操作。在一些实施例中，这些活动可以在这些元件的外部执行，或者包括在某个其他网络元件中以实现该预期的功能。在至少一个实施例中，这些网络元件可以包括可与其他网络元件协调以实现如本文所概述的操作的逻辑(或往复式逻辑)。此外，一个或多个设备可以包括促进其操作的任何合适的算法、硬件、固件、软件、组件、模块、接口、或对象。

在某些示例性实施方式中，本文概述的触发式带内oam能力可通过在一个或多个有形介质(例如，在专用集成电路(asic)、数字信号处理器(dsp)指令、要被一个或多个处理器或其他类似机器运行的软件(可能包括目标代码和源代码)、软件、硬件、固件、或它们的组合中的指令中提供的嵌入式逻辑)中编码的逻辑来实现。在至少一个实施例中，该有形介质可以是非暂态的。在这些实例的一些中，一个或多个存储器元件可存储用于本文所述的操作的数据。这包括能够存储软件、逻辑、代码、和/或处理器指令的存储器元件，这些指令被执行以执行本文所述的动作。处理器可运行与数据相关联的任意类型的指令。在一个示例中，处理器可将元素或物品(例如，数据)从一个状态或事物转换到另一状态或事物。在另一示例中，本文概述的活动可采用固定逻辑或可编程逻辑(例如，由处理器运行的软件/计算机指令)来实现，并且本文标识的元件可以是某种类型的可编程处理器、可编程数字逻辑(例如，现场可编程门阵列(fpga)、可擦可编程只读存储器(eprom)、电可擦可编程rom(eeprom))，或包括数字逻辑、软件、代码、电子指令的asic，或它们任意合适的组合。

如本文所概述的，这些网络元件中的任一者或多者都可以包括用于存储要用于实现触发式带内oam能力的信息的存储器。此外，这些网络元件可以包括至少一个处理器，其可以运行软件、算法、或其他指令以执行(如本文所公开的)触发式带内oam操作。这些网络元件还可以在适当的情况下并根据特定需求将要用于实现如本文所讨论的触发式带内oam能力的信息保存在任何合适的存储器元件(三态内容寻址存储器(tcam)、随机存取存储器(ram)、只读存储器(rom)、eprom、eeprom、asic等)、软件、硬件、或任何其他合适的组件、设备、元件、或对象中。本文讨论的任何存储器项目(例如，存储库、存储器、数据库、表格、缓存、缓冲器等)应该被解释为包含在广义术语“存储器元件”内。类似地，本文描述的任何可能的处理元件、模块、和机器应被解释为被包含在广义术语“处理器”内。每个网络元件还可包括用于在网络环境中接收、发送、和/或以其他方式传输数据或信息的适当接口。

需要注意的是，根据本文提供的示例，可用两个、三个或四个元件来对交互进行描述。然而，这样做仅是为了清楚和举例的目的。在某些情况下，通过只参考有限数目的网络元件能够更容易地描述给定流集的一个或多个功能。应当认识到，本文描述的系统是可轻易扩展的并且可容纳大量数目的组件以及更复杂/精巧的布置与配置。因此，所提供的示例不应该限制触发式带内oam的各种实施例的范围或抑制其可能被应用于很多其他架构中的广泛教导。

如本文所使用的，除非相反地指明，否则短语“至少一个”的使用是指的是指定元件、条件或活动的任意组合。例如，“x、y和z中的至少一者”意在表示以下任何一项：1)x，而不是y也不是z；2)y，而不是x也不是z；3)z，而不是x也不是y；4)x和y，而不是z；5)x和z，而不是y；6)y和z，而不是x；或者7)x，y和z。此外，除非相反地指明，否则术语“第一”、“第二”、“第三”等旨在区分它们修饰的特定名词(例如，元件、条件、模块、活动、操作等)。除非相反地指明，否则这些术语的使用并不意味着至少所修饰名词的任何类型的顺序、级别、重要性、时间序列、或层级。例如，“第一x”和“第二x”旨在指定两个不同的x元素，它们不必受到这两个元素的任何顺序、级别、重要性、时间序列或层级的限制。

同样重要的是要注意，本文中所示出和所描述的活动、交互和操作仅说明了可由具有触发式带内oam能力的节点或在该节点中运行的一些可能的互操作性场景和模式。这些活动、交互和/或操作中的一些可在适当时被删除或移除，或者在不背离本公开的范围的情况下可进行适当修改或改变。此外，许多这样的活动、交互和/或操作可以和一个或多个额外活动、交互和/或操作同时执行或并行执行。但是，这些活动、交互和/或操作的时序可会进行适当的更改。提供上面的操作流程用于举例和论述的目的。具有触发式带内oam能力的网络元件提供的实质的灵活性在于：在不背离本公开的教导的情况下，可设置任何合适的布置、发生顺序、配置、和时序机制。此外，这些活动可以通过各种模块和/或组件来实现，其中，这些模块和/或组件可以基于特定配置和/或设置需求以任何适当的方式进行适当组合，或以任何适当的方式进行分割。

虽然已经参考特定布置和配置详细描述了本公开，但是在不脱离本公开的范围的情况下，这些示例配置和布置可以被显著地改变。而且，根据特定的需求和实施方式，可以对某些组件进行组合、分割、消除或增添。此外，尽管本文中的实施例已参照特定元件和协议进行了说明，但是这些元件和协议可以被实现本文所公开的触发式带内oam的预期功能的任何合适的架构、协议和/或过程所替代。