使用可编程的资源依赖性数学模型来执行根本原因分析

摘要

本公开的实施例涉及使用可编程的资源依赖性数学模型来执行根本原因分析。一种控制器设备管理多个网络设备。控制器设备包括：存储器，存储器被配置为存储依赖性模型与已编程的合并策略，该依赖性模型表示由网络设备提供的资源之间的依赖性；以及一个或多个处理器，一个或多个处理器被实现在电路装置中并且被配置为：确定由网络设备提供的资源；根据已编程的合并策略来确定资源之间的关系；使用所确定的关系来构造依赖性模型；确定资源中的至少一种资源已经经历故障；以及使用依赖性数学模型来执行根本原因分析，以确定资源中的至少一种资源的故障的根本原因。

说明书

技术领域

本公开涉及计算机网络，并且更具体地，涉及对网络设备的管理。

背景技术

计算机网络是可以交换数据和共享资源的互连计算设备的类集。各种设备进行操作以支持计算设备之间的通信。例如，计算机网络可以包括路由器、交换机、网关、防火墙以及用于提供和支持网络通信的各种其他设备。

这些网络设备通常包括用于在本地或者远程地配置设备的机构(诸如，管理接口)。通过与管理接口交互，客户端可以执行配置任务以及执行操作命令，以收集和查看被管理的设备的操作数据。例如，客户端可以配置设备的接口卡，调整针对支持的网络协议的参数，指定设备内的物理组件，修改路由器所维护的路由信息，访问驻留在设备上的软件模块和其他资源，以及执行其他配置任务。另外，客户端可以允许用户查看当前操作参数、系统日志，与网络连接性相关的信息、网络活动或者来自设备的其他状态信息，以及查看从设备接收到的事件信息并且对其做出反应。

网络配置服务可以由多个不同的设备执行，诸如，具有服务卡的路由器和/或专用服务设备。这种服务包括连接性服务，诸如，层三虚拟专用网(L3VPN)、虚拟专用局域网服务(VPLS)和对等(P2P)服务。其他服务包括网络配置服务，诸如，Dot1q VLAN服务。网络管理系统(NMS)和NMS设备(也被称为控制器或者控制器设备)可以支持这些服务，使得管理员可以容易地创建和管理这些高级网络配置服务。

特别地，设备的用户配置可以被称为“意图(intent)”。基于意图的联网系统使管理员描述预期的网络/计算/存储状态。用户意图可以被分类为业务策略或者无状态意图。可以基于网络的当前状态来解决业务策略或者有状态意图。无状态意图可以是描述预期的网络/计算/存储状态而无需关注当前网络状态的完全声明式方式。

意图可以被表示为意图数据模型，可以使用统一图(graph)来对这些意图数据模型进行建模。意图数据模型可以被表示为连通图(connected graph)，使得可以跨意图数据模型实现业务策略。例如，可以使用顶点与实际边(has-edge)和参考(ref)边连接的连通图来表示数据模型。控制器设备可以将意图数据模型建模为统一图，使得可以将意图模型表示为连接的意图模型。按照这种方式，可以跨意图数据模型实现业务策略。当使用统一图模型来对意图进行建模时，扩展新意图支持需要扩展图模型和编译逻辑。

为了将设备配置为执行意图，用户(诸如，管理员)可以编写转换程序，该转换程序将高级配置指令(例如，根据意图数据模型的指令，该意图数据模型可以被表示为统一图模型)转换为低级配置指令(例如，根据设备配置模型的指令)。作为配置服务支持的一部分，用户/管理员可以提供意图数据模型、和意图数据模型与设备配置模型之间的映射。

为了为用户简化映射定义，控制器设备可以被设计为提供按照简单的方式来定义映射的能力。例如，一些控制器设备提供对速度模板和/或可扩展样式表语言变换(XSLT)的使用。这种转换器包含从意图数据模型到低级设备配置模型的转换或者映射逻辑。通常，在意图数据模型中的相对较小数量的改变影响跨设备配置的相对较大数量的属性。当通过意图数据模型创建、更新和删除服务时，可以使用不同的转换器。

发明内容

一般而言，本公开描述了用于管理网络设备的技术。一种网络管理系统(NMS)设备(在本文中也被称为控制器或者控制器设备)可以被配置为将高级配置(从管理员接收到的针对多个被管理的网络设备的意图)转换为低级配置(将被应用于被管理的网络设备本身)。在一些实例中，该控制器设备可以基于意图来维护配置(例如，低级配置)的备份，使得该控制器设备可以将被管理的网络设备恢复到先前的状态(例如，在网络进入不良状态之后)。在一些实例中，管理员向该控制器设备所提供的新意图可能产生可以影响一个或多个现有意图的功能性的冲突，在将该意图部署到一个或多个被管理的网络设备之前，该控制器设备可以检测该冲突—避免使网络处于不良状态。

在一个示例中，一种方法包括：由管理多个网络设备的控制器设备确定由网络设备提供的资源；由控制器设备根据已编程的合并策略来确定资源之间的关系；由控制器设备使用所确定的关系来构造依赖性模型，依赖性模型表示资源之间的依赖性；由控制器设备确定资源中的至少一种资源已经经历故障；以及由控制器设备使用依赖性数学模型来执行根本原因分析，以确定资源中的该至少一种资源的故障的根本原因。

在另一示例中，一种管理多个网络设备的控制器设备包括：存储器，该存储器被配置为存储依赖性模型与已编程的合并策略，依赖性模型表示由网络设备提供的资源之间的依赖性；以及一个或多个处理器，该一个或多个处理器被实现在电路装置中并且被配置为：确定由网络设备提供的资源；根据已编程的合并策略来确定资源之间的关系；使用确定的关系来构造依赖性模型；确定资源中的至少一种资源已经经历故障；以及使用依赖性数学模型来执行根本原因分析，以确定资源中的该至少一种资源的故障的根本原因。

在另一示例中，计算机可读存储介质在其上存储有指令，这些指令在被执行时使管理多个网络设备的控制器设备的处理器：确定由网络设备提供的资源；根据已编程的合并策略来确定资源之间的关系；使用确定的关系来构造依赖性模型，依赖性模型表示资源之间的依赖性；确定资源中的至少一种资源已经经历故障；以及使用依赖性数学模型来执行根本原因分析以确定资源中的该至少一种资源的故障的根本原因。

在附图和下面的描述中阐述了一个或多个示例的细节。其他特征、目的和优点将通过描述和附图以及权利要求书而明显。

附图说明

图1是图示了包括企业网络的使用管理设备来管理的元件的示例的框图。

图2是图示了用于图1所示的管理设备的一组示例组件的框图。

图3是图示了示例图数据库模型的概念图。

图4是图示了资源依赖性数学模型的示例部分的概念图。

图5是图示了示例所发现的网络数据模型的概念图。

图6是图示了根据本公开的技术的用于构造资源依赖性数学模型并且使用该模型来执行根本原因分析(RCA)的示例方法的流程图。

具体实施方式

图1是图示了包括企业网络2的使用控制器设备10来管理的元件的示例的框图。企业网络2的被管理的元件14A至14G(统称为“元件14”)包括经由通信链路被互连以形成通信拓扑以便交换资源和信息的网络设备。元件14(通常也被称为网络设备或者远程网络设备)可以包括：例如，路由器、交换机、网关、桥接器、集线器、服务器、防火墙或者其他入侵检测系统(IDS)或者入侵防御系统(IDP)、计算设备、计算终端、打印机、其他网络设备或者这种设备的组合。虽然在本公开中被描述为传输、传送或者以其他方式支持分组，但是企业网络2可以根据由任何其他协议定义的任何其他分立数据单元(诸如，由异步传输模式(ATM)协议定义的小区，或者由用户数据报协议(UDP)定义的数据报)来传输数据。使元件14互连的通信链路可以是物理链路(例如，光学链路、铜等)、无线链路或者上述的任何组合。

企业网络2被示出为经由通信链路被耦合至公共网络18(例如，互联网)。公共网络18可以包括：例如，一个或多个客户端计算设备。公共网络18可以提供对web服务器、应用服务器、公共数据库、媒体服务器、最终用户设备以及其他类型的网络资源设备和内容的访问。

控制器设备10经由企业网络2被通信地耦合至元件14。虽然出于示例的目的在图1中仅图示了设备管理系统的一个设备，但是在一些示例中，控制器设备10形成设备管理系统的一部分。控制器设备10可以被直接地或者间接地耦合至各种元件14。一旦部署并且激活了元件14，管理员12就使用控制器设备10来使用设备管理协议管理网络设备。一种示例设备协议是简单网络管理协议(SNMP)，它允许控制器设备10遍历和修改在每个被管理的元件14内存储配置数据的管理信息库(MIB)。可以在Harrington等人于2002年12月发表在网络工作组互联网工程任务组草案的RFC 3411“An Architecture for Describing SimpleNetwork Management Protocol(SNMP)Management Frameworks”(在http://tools.ietf.org/html/rfc3411可获得)中找到SNMP协议的进一步细节，其全部内容通过引用并入本文。

在通常的实践中，控制器设备10(也被称为网络管理系统(NMS)或者NMS设备)和元件14由企业的IT组集中维护。管理员12与控制器设备10交互，以远程地监测和配置元件14。例如，管理员12可以从控制器设备10接收有关任何元件14的警告，查看元件14的配置数据，修改元件14的配置数据，向企业网络2添加新的网络设备，从企业网络2移除现有的网络设备，或者以其他方式操纵企业网络2和其中的网络设备。虽然针对企业网络描述本公开的技术，但是本公开的技术可应用于其他网络类型(公共的和私有的)，包括LAN、VLAN、VPN等。

在一些示例中，管理员12使用控制器设备10或者本地工作站来直接与元件14交互，例如，通过远程登录、安全外壳(SSH)或者其他这种通信会话。即，元件14通常提供用于直接交互的接口(诸如，命令行接口(CLI)、基于web的接口、图形用户接口(GUI)等)，用户可以通过这些接口来与设备交互以直接发布基于文本的命令。例如，这些接口通常允许用户直接与设备交互，例如，通过远程登录、安全外壳(SSH)、超文本传输协议(HTTP)或者其他网络会话，以根据定义的语法来录入文本，以向被管理的元件提交命令。在一些示例中，用户使用控制器设备10来发起与元件14之一(例如，元件14F)的SSH会话15，以直接配置元件14F。按照这种方式，用户可以直接以要执行的格式来向元件14提供命令。

进一步地，管理员12还可以创建可以由控制器设备10提交至任何或者所有元件14的脚本。例如，除了CLI接口之外，元件14还提供用于接收根据脚本语言来指定命令的脚本的接口。在某种意义上，脚本可以由控制器设备10输出，以自动对被管理的元件14调用对应的远程过程调用(RPC)。脚本可以符合例如，可扩展标记语言(XML)或者另一种数据描述语言。

管理员12使用控制器设备10来配置元件14，以指定支持管理员12的目标的某些操作特性。例如，管理员12可以为元件14指定有关安全性、设备可访问性、业务工程、服务质量(QoS)、网络地址转换(NAT)、分组过滤、分组转发、速率限制的特定操作策略或者其他策略。控制器设备10使用被设计用于管理在被管理的网络元件14内的配置数据的一种或多种网络管理协议来执行配置，一种或多种网络管理协议诸如，SNMP协议或者网络配置协议(NETCONF)协议或者其派生物，诸如，Juniper设备管理接口。通常，NETCONF提供用于配置网络设备的机制，并且针对配置数据使用基于可扩展标记语言(XML)的数据编码，该配置数据可以包括策略数据。在2006年12月，网络工作组RFC 4741，Enns的“NETCONF ConfigurationProtocol”(在tools.ietf.org/html/rfc4741可获得)中描述了NETCONF。控制器设备10可以与一个或多个元件14建立NETCONF会话。

控制器设备10可以被配置为接受来自管理员12的高级配置数据或者意图(例如，根据YANG，该高级配置数据或者意图可以被表示为结构化输入参数，在2010年10月，互联网工程任务组，RFC 6020，Bjorklund的“YANG—A Data Modeling Language for theNetwork Configuration Protocol(NETCONF)”(在tools.ietf.org/html/rfc6020可获得)中进行了描述)。控制器设备10还可以被配置为输出相应的低级设备配置数据集，例如，设备配置添加、修改和移除。可以在例如，2016年6月30日提交的美国专利申请第15/198,657号—Jiang等人的“TRANSLATING HIGH-LEVEL CONFIGURATION INSTRUCTIONS TO LOW-LEVEL DEVICE CONFIGURATION”中找到有关用于将高级配置信息转换为低级设备配置信息的示例过程的附加细节，其全部内容通过引用并入于此。

在一些示例中，控制器设备10可以将YANG建模用于意图数据模型和低级设备配置模型。该数据可以包含跨YANG实体(诸如，列表项和容器)的关系。在一些示例中，控制器设备10可以将YANG数据模型转换成数据库模型，并且将YANG验证转换成数据验证。在2017年3月17日提交的美国专利申请第15/462,465号—“CONFIGURING AND MANAGING NETWORKDEVICES USING PROGRAM OVERLAY ON YANG-BASED GRAPH DATABASE”中描述了用于使用针对高级配置数据的图模型来管理网络设备的技术，其全部内容通过引用并入于此。

控制器设备10可以接收来自管理员12的数据，该数据表示针对意图数据模型的创建、更新和/或删除动作中的任何或者全部动作。控制器设备10可以被配置为针对被应用于图模型的创建、更新和删除中的每一项使用相同的编译逻辑。

通常，控制器(如控制器设备10)将层次数据模型用于意图、低级数据模型和资源。层次数据模型可以基于YANG或者YAML。如上面讨论的，层次数据模型可以被表示为图。现代系统已经支持简化对网络的管理的意图。意图是声明式的。为了实现意图，控制器设备10尝试选择最佳的资源。客户环境可以被配置为允许客户(例如，管理员12)控制意图实现和确保已编程的意图。在一些示例中，控制器设备10可以通过查询元件14以确定由元件14提供的资源来构造图数据模型。控制器设备10通常可以配置有表示由每个元件14提供的资源的类型的信息，但是可以查询元件14以确定与由元件14提供的每种类型的资源相匹配的资源的特定资源信息。资源的类型可以包括：例如，转发表、路由表、网络访问策略(例如，用于某些用户的访问、防火墙策略等)或者其他这种资源。

根据本公开的技术，控制器设备10还可以被配置为将拓扑模型变换为统一网络模型，并且然后使用统一网络模型来执行对各种网络问题(诸如，设备或资源错误或者故障)的根本原因分析(RCA)。统一网络模型是包含表示网络资源的数据的模型，这些网络资源部分地由域控制器(诸如，控制器设备10)管理。例如，控制器设备10可以表示IP/MPLS控制器、光学控制器或者应用控制器，并且统一网络模型可以是业务工程模型。

本公开认识到：网络连接设备(诸如，物联网(IoT)设备)的数量最近迅速增加。对用于托管云和web应用的大型数据中心的需要已经引起对用于有效地控制设备的复杂的、异构的和分布式网络的机制的需要。这些迅速发展的网络系统需要分布式且快速的诊断解决方案技术来分析依赖事件。

在任何复杂的网络中，网络的基础层中的损坏都可能导致大量更高层服务失败，这可以或者可以不直接关连于发生故障的组件。存在已经提出的用于提供RCA的各种技术。用于关联事件和标识问题的根本原因的技术包括模型遍历技术和依赖性图技术。

模型遍历技术使用对象模型来确定错误(fault)传播。用各种组件和关系来表示网络。基于该模型，可以推断错误依赖性，并且将其用于标识问题的根本原因。与错误传播模型(诸如，依赖性图)不同，模型遍历技术不直接指定错误依赖性，而是允许在运行时间从模型得出错误依赖性。这对频繁改变的网络是有益的，但是不提供更复杂的错误传播场景，因为假设在特定时间仅发生一个问题。

依赖性图技术涉及对依赖性图的使用，该依赖性图是对被管理的对象之间的依赖性进行建模的有向图。在网络的情况下，该图中的节点表示网络元件(例如，主机)，并且从节点A到节点B的边指示节点A中的故障可以导致节点B中的故障，因为节点B依赖于节点A。依赖性图最适合于不经常改变的网络。经常改变的网络需要不断更新依赖性。

如下面更详细地讨论的，控制器设备10可以被配置为使用模型遍历技术和依赖性图技术的组合。此外，用户(诸如，管理员12)可以定义资源和资源发现，以基于客户环境来定制控制器设备10，以执行模型驱动的RCA解决方案。一旦控制器设备10发现了资源，控制器设备10就可以构建允许发现跨资源的依赖性的资源依赖性数学模型。该资源依赖性数学模型提供资源的因果依赖性(cause and effect dependency)之间的关系。

本公开还认识到：模型驱动的RCA可以使用数学形式的统一网络模型来表示依赖性。域控制器(诸如，控制器设备10)可以发现网络模型，并且元件管理系统(EMS)可以执行库存服务以发现设备级资源。本公开描述了一种用于以纳米数学形式来将网络拓扑模型和库存资源变换为统一网络模型的方法。网络模型可以包括经常变化的瞬态模型，诸如，动态标签交换路径(LSP)。控制器设备10可以使用本公开的技术来解决这些瞬态状态。例如，如下面更详细地讨论的，控制器设备10可以使用资源数学模型发现流水线。

为了支持可编程资源数学模型发现技术，控制器设备10可以提供接口，管理员12可以通过该接口来对资源模型(包括设备和网络资源)、资源发现规则和资源合并策略进行编程。控制器设备10还可以基于定义的资源来生成图数据库模型。控制器设备10还可以使用发现流水线来将拓扑模型变换为统一网络模型。控制器设备10可以存留变换后的资源，执行合并策略以构建资源之间的依赖性边，构建依赖性数学模型，处理瞬态改变，以及提供重新同步支持。当改变了基础资源时，控制器设备10可以合并改变。

控制器设备10可以是客户的网络中的现有的、先前部署的控制器设备。控制器设备10可以在本地模型中维护资源。根据本公开的技术，控制器设备10可以是被配置为使资源同步以构建公共资源数据库和对应的数学模型的域特定控制器。

通常，控制器设备10可以对作为剧本(playbook)的一部分的资源提供可编程性支持。一旦应用了剧本，控制器设备10就可以基于已编程的合并策略来变换表示资源的数据并且构建跨资源的关系。在发现资源之后，控制器设备10可以构建允许确定跨资源的因果依赖性的资源依赖性数学模型(也被称为依赖性数学模型)。控制器设备10可以如下构造依赖性数学模型。首先，控制器设备10可以填充资源之间的关系/依赖性边，其中依赖性边可以跨设备资源，跨用于服务的设备资源，以及跨服务。基于该模型，控制器设备10可以构建依赖性数学模型，该依赖性数学模型提供资源的因果关系。

图2是图示了用于图1所示控制器设备10的一组示例组件的框图。在该示例中，控制器设备10包括控制单元22、网络接口34和用户接口36。网络接口34表示可以将控制器设备10通信地耦合至外部设备(例如，图1所示的元件14之一)的示例接口。网络接口34可以表示无线和/或有线接口，例如，以太网接口或者被配置为根据无线标准(诸如，一种或多种IEEE 802.11无线联网协议(诸如，802.11a/b/g/n或者其他这种无线协议))来进行通信的无线电。虽然出于示例的目的仅图示了一个网络接口，但是在各种示例中，控制器设备10可以包括多个网络接口。

控制单元22表示用于实现归因于控制单元22及其组成模块和元件的功能性的硬件、软件和/或固件的任何组合。当控制单元22包括软件或者固件时，控制单元22还包括用于存储和执行软件或者固件的任何必要的硬件，诸如，一个或多个处理器或者处理单元。通常，处理单元可以包括：一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他等效的集成或者分立逻辑电路装置以及这种组件的任何组合。此外，通常使用固定的和/或可编程的逻辑电路装置来实现处理单元。

用户接口36表示一个或多个接口，用户(诸如，管理员12(图1))通过该一个或多个接口与控制器设备10交互，例如，以提供输入和接收输出。例如，用户接口36可以表示监视器、键盘、鼠标、触摸屏、触摸板、触控板、扬声器、相机、麦克风等中的一个或多个。此外，虽然在该示例中，控制器设备10包括用户接口，但是应该理解，管理员12不需要直接与控制器设备10交互，而是可以远程地访问控制器设备10，例如，经由网络接口34。

在该示例中，控制单元22包括用户接口模块38、网络接口模块32和管理模块24。控制单元22执行用户接口模块38以从用户接口36接收输入和/或向用户接口36提供输出。控制单元22还执行网络接口模块32，以经由网络接口34来发送和接收数据(例如，分组)。用户接口模块38、网络接口模块32和管理模块24可以再次被实现为相应的硬件单元，或者被实现在软件或者固件或者其组合中。

控制单元22执行管理模块24以管理各种网络设备，例如，图1所示元件14。管理包括：例如，根据从用户(例如，图1所示管理员12)接收到的指令来配置网络设备，以及向用户提供提交指令以配置网络设备的能力。在该示例中，管理模块24还包括配置模块26和转换模块28。

管理模块24被配置为接收来自用户(诸如，管理员12)的针对一组被管理的网络设备的意图(例如，高级配置指令)。随着时间的推移，用户可以更新配置指令，例如，以添加新服务，移除现有服务，或者修改由被管理的设备执行的现有服务。可以根据例如，YANG来构造意图。在一些示例中，如下面讨论的，管理模块24还向用户提供提交转换功能的能力，转换模块28执行这些转换功能以将意图变换为特定于设备的低级配置指令。

控制器设备10还包括配置数据库40。配置数据库40通常包括描述被管理的网络设备(例如，元件14)的信息。例如，配置数据库40可以包括指示设备标识符(诸如，MAC和/或IP地址)、设备类型、设备供应方、设备种类(例如，路由器、交换机、桥接器、集线器等)等的信息。配置数据库40还基于针对被管理的设备(例如，元件14)的意图(例如，高级配置信息，或者在一些情况下，高级配置信息和低级配置信息两者)来存储设备级配置信息。

转换模块28确定使用配置数据库40来管理哪些设备。转换模块28基于配置数据库40中的信息来确定对高层配置指令执行哪个转换功能30，例如，哪个设备将接收低级配置指令。然后，转换模块28执行转换功能30中的每个确定的转换功能，从而将高级配置指令提供至转换功能作为输入并且接收低级配置指令。然后，转换模块28可以将低级配置指令提供至配置模块26。

在接收到来自转换模块28的低级配置指令之后，配置模块26将低级配置指令发送至相应的被管理的网络设备，针对该相应的被管理的网络设备，配置将经由网络接口模块32被更新。网络接口模块32将低级配置指令传递至网络接口34。网络接口34将低级配置指令转发至相应的网络设备。

虽然出于示例的目的将用户接口36描述为允许管理员12(图1)与控制器设备10交互，但是应该理解，在其他示例中，可以使用其他接口。例如，控制器设备10可以包括可以充当与另一设备的接口的代表性状态转移(REST)客户端(未示出)，管理员12可以通过该代表性状态转移(REST)客户端来配置控制器设备10。同样，管理员12可以通过以下方式来配置元件14：通过REST客户端来与控制器设备10交互。

控制器设备10还在配置数据库40中存储表示由元件14(图1)提供的资源的数据。资源可以包括：例如，元件14的网络服务、硬件和/或软件单元以及表。因此，资源可以包括：例如，网络隧道(诸如，标签交换路径(LSP))、虚拟专用网(VPN)、虚拟路由和转发(VRF)表、硬件接口、逻辑接口等。控制器设备10可以配置有剧本，管理员12(图1)可以使用该剧本来对各种资源进行编程。剧本可以包含一组资源定义、资源发现规则和资源合并策略。

下面示出了针对剧本的示例数据集：

此外，下面示出了剧本的示例接口发现规则：

下面的表1表示对资源及其属性的一组示例描述：

表1

管理模块24可以基于上面示出的资源定义来自动生成数据库模型(以图的形式)。针对数据库模型的图可以包括一组节点，每个节点与资源相对应。该图还可以如下面讨论的那样包括节点之间的边。数据库模型可以根据下面的表2包括字段：

表2

管理模块24可以在针对数据库模型的图中形成表示资源的节点之间的两种类型的边。这两种类型的边包括依赖性边和父-子边。依赖性边创建两种资源之间的参考边。对于依赖性边，引用者对象包含参考属性。父-子边(或者包含边)表示对应的资源之间的父子关系。父对象包含子属性。

图3是图示了示例图数据库模型的概念图。在该示例中，图数据库模型包括设备节点50、虚拟路由和转发(VRF)节点52、接口节点54和逻辑接口节点56。在该示例中，图数据库模型具有在设备节点50与接口节点54之间的包含边60，这指示与设备节点50相对应的设备包括(即，“具有”或者包含)接口，即，由接口节点54表示的物理接口。在该示例中，图数据库模型还具有在VRF节点52与接口节点之间的依赖性边62，这表示与VRF节点52相对应的VRF依赖于与接口节点54相对应的物理接口。因此，当使用与VRF节点52相对应的VRF时，与接口节点54相对应的物理接口的故障也可能导致故障。

参照回图2，控制器设备10及其管理模块24可以执行资源发现流水线。在设备/设备组上使剧本初始化之后，管理模块24可以使用资源发现流水线来一般地处理任何资源(例如，向针对数据库模型的图添加节点)。流水线可以包括资源管理阶段、资源之间的依赖性边管理阶段以及资源依赖性数学模型生成阶段。

在发现资源之后，管理模块24可以执行流水线中的资源管理阶段以构建和更新跨资源的父子关系。管理模块24可以执行以下算法以构建和更新父子关系：

●检查资源是否是瞬态的。

●如果不是瞬态的：

○获得剧本中的现有资源。

○将资源与现有资源相比较。

○生成/更新资源。

○形成“经更新的资源ID列表”，并且将ID列表传递至第二阶段。

●如果是瞬态的：

○布置父/子ID。

○直接将资源传递至第二阶段。

在资源发现阶段之后，管理模块24可以执行资源之间的依赖性边管理阶段。在该阶段期间，管理模块24可以在数据库模型中在与资源相对应的节点之间添加(或者移除)资源依赖性边。管理模块24可以根据以下算法来构建关联合并策略：

●基于经更新的资源ID列表来获得资源。

●基于合并策略规则，获得依赖的资源

●运行合并策略规则

○该步骤的执行包括在针对数据库模型的图中添加/删除在表示资源的节点之间的依赖性边。

●形成“经更新的关联列表”，并且将其传递至下一阶段。

●如果资源是瞬态资源，则通过输入流来构建/更新关系。

控制器设备10还包括依赖性模型42。依赖性模型42表示根据本公开的技术的资源依赖性数学模型。管理模块24可以根据本公开的技术来构造依赖性模型42，并且使用依赖性模型42(即，依赖性图)和模型遍历的组合来执行根本原因分析(RCA)，即，标识各种资源的问题的原因。在2020年3月17日提交的美国申请第16/821,745号中更详细地描述了RCA，其全部内容通过引用并入于此。类似地，在2020年7月14日提交的美国申请第16/946,994号中描述了控制器设备10可以附加地执行或者作为RCA的代替而执行(并且使用依赖性模型42)的故障影响分析技术，其全部内容通过引用并入于此。此外，在2019年12月31日提交的美国申请第16/731,372号中描述了控制器设备10可以附加地执行或者作为RCA和/或故障影响分析技术的代替而执行的、多个层的模型相关性分析技术，其全部内容通过引用并入于此。

图4是图示了资源依赖性数学模型的示例部分的概念图。在该示例中，资源依赖性数学模型包括资源A节点70、资源C节点72和资源B节点74。根据资源依赖性数学模型，如果资源A使用资源B(如通过从资源A节点70到资源B节点74的边76示出的)，则管理模块24按照相反的顺序来确定依赖性。可以提供以下数学模型：

●依赖性(资源):[资源列表]

●对于图4所示示例：依赖性(资源B)→[资源A、资源C]

再次参照图2，如上面讨论的，管理模块24可以在添加和更新资源的依赖性边之后构建依赖性模型42的资源依赖性数学模型。然后，管理模块24可以将资源依赖性数学模型填充为{键,值}对。此处，键元素表示依赖的资源，并且值元素是参考资源的列表。对于每次更新，管理模块24可以相应地更新反向依赖性映射。

管理模块24还可以执行资源同步。在网络2(图1)中，可以相应地添加、更新或者删除资源。管理模块24可以在模型中使这些改变的资源同步。管理模块24可以执行流水线以无缝地说明经更新的(例如，添加的、经更新的或者删除的)资源。管理模块24还可以通过基于剧本获取现有资源并且相对于现有资源产生差值(增量)，来说明资源持久性。在资源关联阶段期间，管理模块24可以更新针对经更新的资源的关联。在资源依赖性数学模型阶段期间，管理模块24可以更新反向依赖性。

如上面讨论的，控制器设备10可以是先前部署在客户网络中的域控制器(或者与该域控制器交互)，并且可能已经在本地模型中维护资源。在该场景中，控制器设备10可以被配置为将来自域特定控制器的资源同步到公共资源数据库。

可以如在下面的示例中示出的那样对资源进行建模：

在上面的示例中，“controller.rule”包含适配器细节。使用适配器，管理模块24可以获取所需的资源。

管理模块24可以确定通过外部控制器发现的资源，并且为这些资源填充关系和数学模型。管理模块24还可以通过流水线来传递这些资源，以同样为这些资源构建数学模型。

根据2018年3月，IETF RFC 8345，Clemm等人的“A YANG Data Model for NetworkTopologies”(在tools.ietf.org/html/rfc8345可获得)，网络和网络资源模型可以如下面描述的那样。网络数据模型使得能够定义网络层次结构或者网络堆栈(即，层叠在彼此之上的网络)以及维护网络中所包含的节点的库存。网络数据模型还提供用于描述拓扑信息的信息。具体地，其可以添加“链路”和“端点(termination point)”的概念来描述网络中的节点连接至彼此的方式。网络数据模型引入了网络之间的垂直分层关系，可以增强这些关系以涵盖网络库存和网络/服务拓扑。

图5是图示了示例所发现的网络数据模型的概念图。在该示例中，所发现的网络数据模型包括网络资源1 80、网络资源2 110和设备/节点1 90。网络资源1 80包括节点D182、D2 84和D3 86。设备/节点1 90包括节点D1 92、R1 94、R2 96、R3 98和R4 100。网络资源2 110包括节点D1 112、D2 114和D3 116。

在该示例中，节点D1 82具有到节点D2 84、D3 86、R1 94和R3 98的参考边，而节点D2具有到节点D3 86的参考边。类似地，节点D1 112具有到节点D2 114和D3 116的参考边，而节点D2 114具有到节点D3 116的参考边。此外，从节点D1 82到节点D2 84的参考边本身具有到节点R3 98的参考边。类似地，从节点D1 82到节点D3 86的参考边具有到从节点D1112到节点D2 114以及从节点D2 114到节点D3 116的参考边的参考边。附加地，网络资源180具有到网络资源2 110的参考边。

按照这种方式，图5所示模型包括演示了层叠在彼此之上的网络的网络层次结构(即，网络堆栈)。

图6是图示了根据本公开的技术的用于构造资源依赖性数学模型并且使用该模型来执行根本原因分析(RCA)的示例方法的流程图。在该示例中，例如，如上面讨论的，控制器设备10(图1和图2)接收包括数据的剧本(130)，该数据表示资源定义、资源发现规则和资源合并策略的集合。

然后，控制器设备10可以使用剧本来确定网络的资源(132)。例如，控制器设备10可以将数据库模型生成为图，并且向该图添加与资源相对应的节点和节点之间的边。特别地，控制器设备10可以根据剧本中的资源定义、发现规则和合并策略来发现资源。控制器设备10还可以确定资源是否是瞬态的，并且当资源是瞬态的与非瞬态的时，不同地处理资源。

控制器设备10还可以确定资源之间的关系(134)。例如，控制器设备10可以确定资源是否具有父子关系或者包含关系。控制器设备10可以相应地更新图中的资源依赖性边(136)，例如，通过将边定义为包含边(即，父子边)或者依赖性边。控制器设备10可以在确定依赖的资源时使用合并策略规则来添加或者删除在表示资源的节点之间的依赖性边。因此，控制器设备10可以生成依赖性模型(138)。

此外，控制器设备10可以监测网络以获得对资源的修改，例如，以检测资源添加、更新和删除。控制器设备10还可以确定这种修改是否与瞬态资源相对应。控制器设备10还可以更新依赖性模型，即，图中的节点和边，以相应地在依赖性模型中使资源同步(140)。

在某一时刻，控制器设备10可以检测到资源已经发生故障(142)。作为响应，控制器设备10可以使用依赖性模型来执行根本原因分析(RCA)(144)，以标识发生故障的资源的根本原因。通常，控制器设备10可以通过发生故障的资源所依赖的资源来追溯故障以最终标识导致故障的资源。例如，网络隧道(例如，LSP)的故障可以追溯到特定设备的网络接口的故障。

按照这种方式，图6所示的方法表示一种方法的示例，该方法包括：由管理多个网络设备的控制器设备确定由网络设备提供的资源；由控制器设备根据已编程的合并策略来确定资源之间的关系；由控制器设备使用确定的关系来构造依赖性模型，依赖性模型表示资源之间的依赖性；由控制器设备确定资源中的至少一种资源已经经历故障；以及由控制器设备使用依赖性数学模型来执行根本原因分析，以确定资源中的该至少一种资源的故障的根本原因。

本公开中所描述的技术可以至少部分地被实现在硬件、软件、固件或者其任何组合中。例如，所描述的技术的各个方面可以被实现在一个或多个处理器中，包括：一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者任何其他等效的集成或者分立逻辑电路装置以及这种组件的任何组合。术语“处理器”或者“处理电路装置”通常可以是指任何前述的逻辑电路装置(单独地或者结合其他逻辑电路装置)或者任何其他等效的电路装置。包括硬件的控制单元也可以执行本公开的一种或多种技术。

这种硬件、软件和固件可以被实现在同一设备内或者单独的设备内以支持本公开中所描述的各种操作和功能。附加地，所描述的单元、模块或者组件中的任何一个可以被一起或者单独地实现为分立的但是可互操作的逻辑设备。将不同的特征描述为模块或者单元旨在高亮不同的功能方面，并且不一定暗示必须通过单独的硬件或者软件组件来实现这种模块或者单元。相反，与一个或多个模块或者单元相关联的功能性可以由单独的硬件或者软件组件执行，或者被集成在共同的或者单独的硬件或者软件组件内。

本公开中所描述的技术还可以被实施或者编码在包含指令的计算机可读介质(诸如，计算机可读存储介质)中。被嵌入或者编码在计算机可读介质中的指令可以使可编程处理器或者其他处理器执行该方法，例如，当指令被执行时。计算机可读介质可以包括非瞬态计算机可读存储介质和瞬态通信介质。计算机可读存储介质(该计算机可读存储介质是有形的并且非瞬态的)可以包括：随机存取存储器(RAM)、只读存储器(ROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPRQM)、闪速存储器、硬盘、CD-ROM、软盘、磁带盒、磁性介质、光学介质或者其他计算机可读存储介质。术语“计算机可读存储介质”是指物理存储介质，而不是信号、载波或者其他瞬态介质。

已经描述了各种示例。这些以及其他示例在以下权利要求书的范围内。