统一策略代理

背景技术

本公开通常涉及网络管理和联网策略领域。通常，网络可以包括多个相互连接的网络设备，其中至少一个或多个网络设备实施策略强制执行引擎(policy enforcementengine)。在典型的网络中，多个不同的策略强制执行引擎可以沿网络路径存在，用于强制执行联网策略以管理网络业务。每个策略强制执行引擎可以与不同的性能特征和能力相关联。

附图说明

图1图示了根据本申请的一个方面的用于促进统一策略代理的包括计算机系统的示例网络环境。

图2图示了根据本申请的一个方面的用于促进统一策略代理的示例系统架构。

图3呈现了根据本申请的一个方面的用于促进统一策略代理的示例过程。

图4呈现了根据本申请的一个方面的流程图，图示了用于基于统一策略代理对策略强制执行引擎进行配置和管理的示例过程。

图5图示了根据本申请的一个方面的用于从强制执行器列表中选择强制执行器的示例用户接口。

图6图示了根据本申请的一个方面的促进统一策略代理的示例计算机系统。

在图中，相同的附图标记指的是相同的图元素。

具体实施方式

以下描述是为了使本领域中的任何技术人员都能够制作和使用示例而被呈现的，并且是在特定应用和其要求的背景下被提供的。对所公开的示例的各种修改对于本领域技术人员来说是明显的，并且在不偏离本公开的精神和范围的情况下，本文中所定义的一般原理可以应用于其他示例和应用。因此，本公开的范围并不限于所示的示例，而是应符合与本文所公开的原理和特征相一致的最广范围。

驻留在网络中的各种网络设备都可以配备有策略强制执行引擎。策略强制执行引擎可以是能够实施一组联网策略的软件组件或硬件组件。例如，访问控制列表(ACL)可以是联网策略，能够允许用户使用应用编程接口(API)指定规则来拒绝特定类型的业务。此外，联网策略也可以对应于转发规则，例如基于策略的转发(PBF)或防火墙规则。不同的策略强制执行引擎可以与不同类型的API相关联。例如，一个API可以支持某种描述或表示策略的方式，而另一个API可以使用不同的策略表示语言。

每个策略强制执行引擎都可以强制执行(enforce)一个或多个联网策略来管理网络业务。例如，沿着网络业务路径的第一网络设备中的一个策略强制执行引擎可以强制执行网络安全策略，而沿着网络业务路径的第二网络设备中的另一个策略强制执行引擎可以强制执行业务管理策略。换句话说，网络交换机中的ACL可以对应于第一策略强制执行引擎，防火墙设施或分布式防火墙中的防火墙规则可以对应于第二策略强制执行引擎。

不同类型的策略强制执行引擎可以与不同的应用编程接口(API)相关联。每种类型的API都可以利用不同的术语来表示策略。例如，与第一策略强制执行引擎相关联的API可以利用特定的术语来表示策略函数，而与第二策略强制执行引擎相关联的另一个API可以利用不同的术语来表示类似的策略函数。尽管沿着网络路径存在不同类型的策略强制执行引擎可以为网络管理员提供灵活性，但是使用不同的管理API对它们进行手动配置可能是困难和复杂的。这是因为这些“强制执行器”或策略强制执行引擎中的每一个都可以有自己的用户接口和API，并且可以经常对相同的功能使用不同的术语。因此，对于用户来说，学习与不同的策略强制执行引擎相关联的这些不同术语，并且然后手动配置它们可能是困难和复杂的。

本申请中所描述的一些方面通过为统一策略代理提供系统和方法为上述技术问题提供了技术解决方案，该统一策略代理可以提供单一的用户体验和单一的API来配置和管理各种执行选项。例如，系统可以在不同的策略强制执行引擎上使不同的术语、工作流程和能力标准化。然后，系统可以在不同的策略强制执行引擎上提供一组标准化的工作流程，以便用户可以在这些引擎上配置可以相互作用和补充的网络策略。换句话说，系统可以为用户提供使用相同服务组或限定符(例如应用)创建策略规则的灵活性。然后，用户可以简单地将策略类型或强制执行器更改为网络ACL类型强制执行器或分布式防火墙类型强制执行器。响应于选择特定类型的强制执行器，系统可以确保所创建的策略规则以正确的实施方式呈现。具体来说，给定公共的能力集，给定用于定义规则的统一语言或API，用户可以在不同的实施方式(例如东西防火墙)之间来回切换。系统还可以验证规则是否可以应用于新的目标强制执行器，从而允许不同的强制执行器之间的无缝迁移。

具体来说，系统可以自动监测网络，以获得与不同的策略模型相关联的配置信息，这些策略模型与网络中的对应策略强制执行引擎相关联。换句话说，系统可以获得关于每个策略模型如何创建策略、定义策略、定义策略规则等的信息。基于该信息，系统可以在统一策略模型与不同的策略模型之间创建映射。这种统一策略模型可以经由用户接口提供统一的API，用于使用不同的策略模型配置和管理不同的策略强制执行引擎。

短语“策略强制执行引擎”指的是网络设备中可以强制执行一组策略规则的软件和/或硬件组件。

短语“策略强制执行引擎”和“强制执行器”在本申请中可以互换使用。

系统架构

图1图示了根据本申请的一个方面的用于促进统一策略代理的包括计算机系统的示例网络环境。在图1所示的示例中，环境100显示一组网络设备或网络设施，例如网络设备110-114，驻留在网络126中。网络设备110-114，例如网络交换机，可以基于相应的策略强制执行引擎实施联网策略。这些联网策略可以包括一组转发规则，当满足某些匹配标准时，这些转发规则可以应用于网络分组。

例如，一个网络设备可以支持ACL类型策略强制执行引擎，而另一个网络设备可以支持防火墙类型策略强制执行引擎。此外，防火墙类型的策略强制执行引擎可以与ACL类型的策略强制执行引擎具有类似的策略相关功能。然而，每个策略强制执行引擎都可以与其自己类型的API(例如API 116-120)相关联。换言之，与策略强制执行引擎相关联的API可以包括策略函数的术语和表示，这与类似的策略函数的另一个API不同。策略函数可以与策略、策略强制执行选择(允许、否认、排斥等)、策略规则、业务规范等相关联。

手动管理和配置与特定API相关联的这些不同的策略强制执行引擎可能是复杂和不同的。这是因为用户可能必须了解用于不同和类似的策略函数的不同策略强制执行引擎上所使用的不同术语。此外，用户可能必须了解网络设备处的能力、可用的计算和存储器资源以及沿网络路径的路径效率，以便能够配置适当的策略强制执行引擎，以通过具有所需的性能属性的高效方式交付网络流。

本申请中所描述的一个方面可以通过提供统一策略代理为上述问题提供技术解决方案，该统一策略代理可以促进通过单一控制点配置和管理策略强制执行引擎。统一策略代理106可以经由用户接口104使用统一API 122促进不同的策略强制执行引擎的管理。例如，实施统一策略代理106的计算机系统102可以提供单一控制点，以使用统一的或单一的一组策略定义和结构元素跨不同的策略强制执行引擎配置各种类型的策略。此外，除了提供统一API，统一策略代理106还可以适应策略强制执行引擎上存在的能力差异，例如性能特性、业务强制执行选项、资源可用性等。例如，不同的能力还可以包括在对应网络设备处可用的存储器数量、与网络设备相关联的策略强制执行引擎所支持的策略规则数量、添加到给定网络业务流的延迟、与策略强制执行引擎相关联的性能特性、由策略强制执行引擎所提供的流量强制执行选项，等等。

此外，统一策略代理106可以通过与显示设备124相关联的用户接口(UI)104提供统一API 122来配置和管理不同的策略强制执行引擎。在该申请的一个方面中，系统102可以通过图形用户接口为用户108提供可视化，该图形用户接口可以包括关于网络126中的不同策略强制执行引擎的信息、关于策略如何跨多个策略强制执行引擎在给定网络业务流上强制执行的信息，等等。下面参照图2至图6描述统一策略代理106的操作。

图2图示了根据本申请的一个方面的用于促进统一策略代理的示例系统架构。在图2所示的示例中，系统架构200可以包括计算机系统202，该计算机系统具有用于提供单一的用户体验的集成控制器或统一策略代理206以及用于配置和管理与网络234中的网络设备相关联的不同策略强制执行引擎的单一API。网络234可以包括一组相互连接的网络设备，例如216-220。网络234中的至少两个或两个以上的网络设备可以包括策略强制执行引擎。例如，网络设备216-220可以分别包括策略强制执行引擎228-232。

统一策略代理(UPB)206可以包括网络监测模块210，该网络监测模块210能够实施监测机制，以提供对与网络234相关联的各种属性的广泛可见性，例如在服务器上运行的虚拟联网基础设施、可以促进确定网络业务所采取的路径的其他种类的数据、与服务器、网络设备相关联的配置信息和与虚拟联网相关联的其他配置信息。

网络监测模块210还可以监测和检索与驻留在网络中的网络设备中的能力和资源可用性相关联的信息、基于沿着网络路径的不同策略强制执行引擎的与网络路径的效率相关的信息，等等。例如，支持ACL类型策略强制执行引擎的网络交换机可以提供有限的资源能力，而支持防火墙类型策略强制执行引擎的网络设施可以支持大量的策略规则，例如按照成千上万的策略规则，因此可以提供增强的资源能力。此外，网络监测模块210可以检索网络信息，该网络信息可以提供端到端可见性，例如监测网络业务所采取的路径，使得UPB206能够应用特定的策略规则。例如，UPB 206可以为给定的网络业务流确定沿着第一主机上的第一虚拟机和第二主机上的第二虚拟机之间的路径存在的不同类型的策略强制执行引擎。UPB 206可以使用户能够应用统一API，经由用户接口204选择沿着网络路径的一个或多个策略强制执行引擎，以应用某种策略规则来管理从第一虚拟机移位到第二虚拟机的网络业务。网络监测模块210可以不限于监测上述属性，而且还可以扩展到提供对虚拟联网栈和其他网络属性的可见性，这些网络属性可以提供网络环境的改进视角。

每个策略强制执行引擎可以有自己的用户接口和API。例如，策略强制执行引擎228、230和232可以分别与API 222、224和226相关联。与策略强制执行引擎226相关联的API222可以使用第一表示或第一术语来定义策略函数，例如策略规则、业务规范、强制执行选择(例如允许、否认、排斥等)。与策略强制执行引擎230相关联的API 224可以使用针对类似的策略函数的第二表示或第二术语。在现有的系统中，用户可以应用策略强制执行引擎特定的API来配置策略强制执行引擎。换句话说，期望用户了解在不同的API上用于不同的策略强制执行引擎上的类似的策略函数的不同术语和定义，以便能够配置策略强制执行引擎。

此外，由于多样性的一组API，用户可以发现找出与不同的策略强制执行引擎相关联的不同策略函数如何进行交互和/或相互关联是困难和复杂的。理解沿着网络路径存在的不同策略强制执行引擎之间的这种相互关系，可能与确保策略强制执行引擎的操作不会彼此冲突相关。换句话说，用户可以在第一网络设备中配置ACL类型策略强制执行引擎，以允许网络业务转发给第二网络设备。如果第二网络设备是防火墙设施，则用户可能必须确保防火墙类型策略强制执行引擎没有被配置为阻止网络业务。

随着网络环境中不同类型的策略强制执行引擎的增加，并且由于多个策略强制执行引擎具有自己的界面和API，可以使得策略强制执行引擎的手动配置和管理困难和复杂。例如，由于不同类型的策略强制执行引擎可以沿着端到端的物理或逻辑网络存在，用户可能必须去这些基础设施中的每一个，并且理解哪些类型的策略可以相互关联，以便沿着与网络业务相关联的网络路径应用统一和一致的策略强制执行。

在本申请中所描述的一个方面中，网络监测模块210可以监测和检索配置信息，该配置信息可以包括关于如何应用与策略强制执行引擎相关联的策略模型来创建一个或多个策略和策略规则的信息、关于策略模型如何表示一个或多个策略和策略规则的信息、关于策略模型如何表示与策略强制执行引擎相关联的一个或多个能力的信息。

UPB 206可以基于由网络监测模块210检索到的配置信息和其他信息，应用统一策略模型模块212将类似的策略函数的不同描述或表示译成统一描述。换句话说，统一策略模型模块212可以应用从网络监测模块210检索到的配置信息和其他信息来提供统一API。用户可以经由用户接口204应用统一API来配置和管理在网络环境中部署的不同类型的策略强制执行引擎。因此，UPB 206可以提供具有单一的用户体验的统一API来配置、管理和监测各种强制执行器。

换句话说，通过统一API和单一的用户接口，用户可以配置和管理不同类型的策略强制执行引擎，而没有学习和理解不同的API上所使用的不同术语的负担。具体来说，统一策略模型模块212可以基于网络监测模块210所获得的配置信息，将与不同的策略强制执行引擎相关联的不同术语以及其相应的API转换为统一术语，即将不同的术语译成统一表示。此外，统一策略模型模块212可以在网络234中的强制执行器228-232上使不同的术语、工作流和能力标准化。

跨强制执行器228-232的一组标准化工作流程可以允许用户在强制执行器上配置网络策略，这些强制执行器可以相互作用和补充。例如，网络交换机上的ACL类型强制执行器可以为某个路径上允许的业务提供过滤器，然后，该路径上的附加强制执行器(诸如防火墙设施)可以进一步检查和修改该业务。

在本申请的一个方面中，统一策略模型模块212可以获得为网络环境(其中每个网络设备都提供不同的策略强制执行引擎)中的不同网络设备配置的现有策略定义，并且可以在统一策略模型和与对应的策略强制执行引擎相关联的不同策略模型之间创建映射。这种统一策略模型可以用于经由用户接口提供统一的API，用于使用不同的策略模型配置和管理不同的策略强制执行引擎。换句话说，统一策略模型模块212可以为执行类似的策略函数的各种策略强制执行引擎创建统一对象模型。此外，统一策略模型模块212还可以适应和保留存在于不同的策略强制执行引擎之间的一些相关差异，例如性能特性、业务强制执行选项、能力等。

配置模块214可以基于统一API 208分别在网络设备216-220上配置策略强制执行引擎，即228-232。例如，用户可以经由用户接口204应用统一API 208来选择策略强制执行引擎(例如，与网络设备220相关联的策略强制执行引擎232)用于强制执行给定策略。在一个方面中，用户接口204可以提供可视化，该可视化可以包括关于网络234中不同的策略强制执行引擎的信息、关于如何跨多个强制执行器对给定的网络业务流执行策略的信息。响应于经由用户接口接收用户输入，例如用户输入可以包括选择一个或多个策略强制执行引擎来强制执行给定的策略规则，配置模块214可以将一个或多个API命令发送给相应的所选的策略强制执行引擎。API命令可以包括将所选的策略强制执行引擎配置为强制执行一个或多个给定的策略规则的请求。配置模块214可以基于统一API 208将API命令发送给相应的网络设备，以将给定策略添加到在网络设备处维护的策略查找表。

在另一个示例中，当用户经由用户接口204使用统一API 208取消选择策略强制执行引擎时，配置模块214可以发送API命令，以编辑或移除相应的策略查找表中的条目，以便包括该策略强制执行引擎的网络设备不充当强制执行点来应用给定策略。执行点可以对应于网络设备接口，在该接口上，策略强制执行引擎可以强制执行给定策略。

在本申请的一个方面中，UPB 206可以应用统一策略模型模块212将统一API命令转换为策略强制执行引擎特定的API命令。例如，当用户经由用户接口204使用统一API 208选择策略强制执行引擎228来强制执行给定策略时，统一策略模型模块212可以将策略函数的统一表示转换为策略函数的策略强制执行引擎API 222特定的表示。基于这种转换，配置模块214可以将一个或多个API特定的命令发送给策略强制执行引擎228，以强制执行给定策略。

图3呈现了根据本申请的一个方面的用于促进统一策略代理的示例过程。参照图3中的流程图300，在操作期间，实施统一策略代理的系统可以动态地监测网络(操作402)，以捕捉与不同的策略强制执行引擎相关联的信息。基于监测，系统可以接收与网络中的不同策略强制执行引擎相关联的配置信息(操作404)。这种配置信息可以包括关于如何应用与策略强制执行引擎相关联的策略模型来创建一个或多个策略和策略规则的信息、关于策略模型如何表示一个或多个策略和策略规则的信息、关于策略模型如何表示与策略强制执行引擎相关联的一个或多个能力的信息。

系统可以基于配置信息学习与网络中不同的策略强制执行引擎上的一组类似的策略定义对应的不同表示(操作306)。系统还可以学习与关联于对应的策略强制执行引擎的一组不同的能力对应的不同表示。系统可以将一组策略规则的不同表示转换为或译成统一表示(操作308)。换句话说，系统可以将与一组类似的策略定义相关联的不同表示映射到统一表示。例如，系统可以基于配置信息分别确定与第一策略强制执行引擎和第二策略强制执行引擎对应的类似策略函数的第一表示和第二表示。系统然后可以应用统一策略模型来执行从类似策略函数的统一表示到第一表示和第二表示的第一映射。统一表示可以提供类似策略函数的统一定义。

系统还可以将与一组不同的能力对应的不同表示映射到多个统一表示，从而保留不同的策略强制执行引擎之间存在的有用差异。例如，系统还可以基于配置信息确定与第一策略强制执行引擎相关联的第一能力的第三表示和与第二策略强制执行引擎相关联的第二能力的第四表示。然后，系统可以应用统一策略模型来执行从第三表示和第四表示到相应的第一统一表示和第二统一表示的第二映射，从而保留与第一策略强制执行引擎和第二策略强制执行引擎相关联的能力差异。然后，系统可以将第二映射添加到统一API，并且可以相应地配置第一策略强制执行引擎和第二策略强制执行引擎。系统可以基于不同的映射创建或提供统一策略模型，从而经由用户接口将统一API提供给用户。这种统一策略模型可以使用户能够经由用户接口应用统一API来配置不同的策略强制执行引擎(操作310)，从而通过统一API提供单一的用户体验和单一的控制点。操作然后返回。

图4呈现了根据本申请的一个方面的流程图，图示了用于基于统一策略代理对策略强制执行引擎进行配置和管理的示例过程。本申请中所描述的一个方面可以提供用户接口，使得用户能够应用统一API基于(在监测过程中检索到的)配置信息和其他信息选择沿着网络路径存在的用于强制执行一个或多个给定策略的一个或多个策略强制执行引擎。

系统可以基于统一API经由用户接口接收用户输入(操作402)。用户输入可以包括选择一个或多个策略强制执行引擎来强制执行一个或多个给定策略规则。响应于接收到用户输入，系统可以确定用户输入是否包括策略强制执行引擎的选择(操作404)。当用户输入包括至少一个策略强制执行引擎的选择时，系统可以基于统一策略模型将策略函数的统一表示转换为策略函数的所选的策略强制执行特定的API表示(操作406)。然后，系统可以基于操作406中的转换将一个或多个API命令发送给所选的策略强制执行引擎，以执行给定的策略规则(操作408)，然后，操作返回。

当用户输入表明至少一个策略强制执行引擎未被选择时，系统可以基于统一策略模型将策略函数的统一表示转换为策略函数的未被选择的策略强制执行特定的API表示(操作410)。然后，系统可以基于操作410中的转换将一个或多个API命令发送给未被选择的策略强制执行引擎，以移除来自策略查找表的给定的策略规则(操作412)，然后，操作返回。

图5图示了根据本申请的一个方面的用于从强制执行器列表中选择强制执行器的示例用户接口。在图5所示的示例中，系统可以提供用户接口500，使得用户能够从强制执行器列表中选择。例如，用户接口500列出两个不同的强制执行器，即ACL类型强制执行器和分布式防火墙类型强制执行器。换言之，系统可以为用户提供使用相同服务组或限定符(例如应用)创建策略规则的灵活性。然后，用户可以简单地将策略类型或强制执行器更改为网络ACL类型强制执行器或分布式防火墙类型执行器。响应于选择特定类型的强制执行器，系统可以确保所创建的策略规则以正确的实施方式呈现。例如，用户接口502表明用户选择了ACL类型强制执行器，并且用户接口504表明用户选择了分布式防火墙类型强制执行器。尽管两种强制执行器都可以实施类似的策略，但是用户具有在两种强制执行器之间选择的灵活性。因此，给定公共的能力集，给定用于定义规则的统一语言或API，用户可以在不同的实施方式(例如东西防火墙)之间来回切换。系统还可以验证规则是否可以应用于新的目标强制执行器，从而允许不同强制执行器之间的无缝迁移。

用于促进自动策略引擎选择的计算机系统

图6图示了根据本申请的一个方面的促进统一策略代理的示例计算机系统。在该示例中，计算机系统600可以包括处理器602、存储器604、存储设备606。计算机系统600可以耦合到外围输入/输出(I/O)用户设备616，例如显示设备608、键盘610和指向设备612。存储设备606可以存储操作系统618、统一策略代理系统620和数据630的指令。数据630可以包括通过本公开中所描述的方法和/或过程作为输入所需或作为输出生成的任何数据。计算机系统600可以经由一个或多个网络接口耦合到网络614。

在本申请的一个方面中，统一策略代理系统620可以包括指令，这些指令在由处理器602执行时可以使计算机系统600执行本公开中所描述的方法和/或过程。统一策略代理系统620可以包括通信模块622，用于经由一个或多个网络接口将网络分组发送给网络614中的其他节点。通信模块622还可以通过一个或多个网络接口从网络614中的其他网络节点接收/获得网络分组。统一策略代理系统620还可以包括指令，以实施网络监测模块624，用于监测网络614和驻留在网络614中的网络设备。此外，网络监测模块624可以应用通信模块624来接收配置信息和与被监测的网络614相关联的一组属性。

统一策略代理系统620可以包括统一策略模型模块626，以确定一组策略定义的统一表示。换句话说，与网络614中的对应网络设备相关联的策略强制执行引擎可以使用特定的API来配置，即不同的策略强制执行引擎可以用不同的API来配置。每个API都可以包括一组策略定义的不同表示或描述。例如，与第一策略强制执行引擎相关联的第一API可以提供策略定义的第一表示，例如策略规则，而与第二策略强制执行引擎相关联的第二API可以提供类似策略规则的第二表示。通常，网络可以包括多个策略强制执行引擎和多个API。用不同的API配置这种策略强制执行引擎可以是复杂和困难的。

统一策略代理系统620可以应用统一策略模型模块626将网络中不同的策略强制执行引擎上的策略定义的这些不同表示转换为统一表示或统一API。换句话说，统一策略模型模块626可以在类似的策略定义的不同表示和统一策略表示之间生成第一种类型的映射，并且在策略强制执行引擎的不同能力的一组不同的表示和一组统一表示之间生成第二种类型的映射，而不是将这种能力差异映射到单一的统一表示。第一种类型的映射为类似的策略函数的不同表示提供统一表示，而第二种类型的映射保留了不同的策略强制执行引擎之间存在的能力差异，例如性能特性、业务强制执行选项等。这种统一API可以用于配置不同的策略强制执行引擎。

配置模块628可以配置一个或多个所选的策略强制执行引擎，以便它们可以强制执行指定的策略规则。在一个方面中，当沿着网络路径的策略强制执行引擎未被选择时，配置模块628可以以策略强制执行引擎不执行给定策略规则的未被指定的子集的方式对其进行配置。

本申请中所描述的一个方面可以提供用于促进统一策略代理的一种系统和方法。在操作期间，系统可以接收来自一组网络设备的配置信息。网络中的至少两个网络设备可以分别配备有第一策略强制执行引擎和第二策略强制执行引擎，用于强制执行一个或多个给定的策略规则。每个策略强制执行引擎都可以与提供类似的策略函数的不同表示的不同API相关联。系统可以基于配置信息分别确定与第一策略强制执行引擎和第二策略强制执行引擎对应的类似策略函数的第一表示和第二表示。此外，系统可以应用统一策略模型来执行从类似策略函数的统一表示到第一表示和第二表示的第一映射。统一表示可以提供类似策略函数的统一定义。基于第一映射，系统可以通过用统一表示来表示类似策略函数的第一表示和第二表示来创建统一API。然后，系统可以经由用户接口应用统一API来配置第一策略强制执行引擎和第二策略强制执行引擎上的类似策略函数。

在该方面的变型中，系统还可以基于配置信息确定与第一策略强制执行引擎相关联的第一能力的第三表示和与第二策略强制执行引擎相关联的第二能力的第四表示。系统然后可以应用统一策略模型来执行从第三表示和第四表示到相应的第一统一表示和第二统一表示的第二映射，从而保留与第一策略强制执行引擎和第二策略强制执行引擎相关联的能力差异。此外，系统可以将第二映射添加到统一API，并且可以基于统一API配置第一策略强制执行引擎和第二策略强制执行引擎。

在这个方面的变型中，第一能力和第二能力包括以下一项或多项：在对应的网络设备处可用的存储器数量、网络设备处的处理资源能力、与网络设备相关联的策略强制执行引擎所支持的策略规则数、添加到给定网络业务流的延迟、与策略强制执行引擎相关联的性能特性和策略强制执行引擎所提供的业务强制执行选项。

在这个方面的变型中，第三表示与第四表示不同。

在这个方面的变型中，用户接口可以包括网络中的不同策略强制执行引擎的可视化以及关于如何跨多个策略强制执行引擎对给定的网络业务流强制执行策略的信息。

在这个方面的变型中，通过响应于确定用户选择了第一策略强制执行引擎用于强制执行一个或多个给定的策略规则，将类似策略函数的统一表示转换为第一表示，并且基于转换，将一个或多个API命令发送给实施第一策略强制执行引擎的网络设备，用于强制执行一个或多个给定的策略规则，系统可以经由用户接口应用统一API在第一策略强制执行引擎和第二策略强制执行引擎上配置类似的策略函数。

在这个方面的变型中，通过响应于确定用户已经取消选择第一策略强制执行引擎来强制执行一个或多个给定的策略规则，将类似策略函数的统一表示转换为第一表示，并且基于转换，将一个或多个API命令发送给实施第一策略强制执行引擎的网络设备，以从策略查找表中移除一个或多个给定的策略规则，系统可以经由用户接口应用统一API在第一策略强制执行引擎和第二策略强制执行引擎上配置类似的策略函数。

在这个方面的变型中，类似的策略函数可以包括以下一项或多项：策略规则、策略、业务规范和一组强制执行选择。

在又一的变型中，第一表示可以与第二表示不同。

在又一的变型中，配置信息可以包括关于如何应用与策略强制执行引擎相关联的策略模型来创建一个或多个策略和策略规则的信息、关于策略模型如何表示一个或多个策略和策略规则的信息以及关于策略模型如何表示与策略强制执行引擎相关联的一个或多个能力的信息。

具体实施方式章节中所描述的方法和过程可以体现为代码和/或数据，该代码和/或数据可以被存储在上述计算机可读存储介质中。当计算机系统读取和执行在计算机可读存储介质上所存储的代码和/或数据时，计算机系统执行体现为数据结构和代码并且被存储在计算机可读存储介质中的方法和过程。

此外，上面描述的方法和过程可以包括在硬件模块或装置中。硬件模块或装置可以包括但不限于ASIC芯片、现场可编程门阵列(FPGA)、在特定时间执行特定软件模块或一段代码的专用或共享处理器和/或现在已知或以后开发的其他可编程逻辑设备。当硬件模块或装置被激活时，它们执行其中包括的方法和过程。

上面对方面的描述是为了说明和描述的目的而提出的。它们并不旨在是详尽的或并不旨在将本公开的范围限于所公开的形式。因此，许多修改和变化对于本领域技术人员而言将是显而易见的。