CN107104894B - 网络控制系统中的控制器 - Google Patents

Abstract

描述了一种用于生成用于管理第一和第二管理转发元件的物理控制平面数据的网络控制系统，第一和第二管理转发元件实现与第一逻辑数据路径集合相关联的转发操作。该系统包括用于将第一逻辑数据路径集合的逻辑控制平面数据转换为通用物理控制平面(UPCP)数据的第一控制器实例。该系统还包括用于将UPCP数据转换为第一管理转发元件而不是第二管理转发元件的自定义物理控制平面(CPCP)数据的第二控制器实例。该系统还包括用于接收由第一控制器实例所生成的UPCP数据、将第二控制器实例标识为负责生成第一管理转发元件的CPCP数据的控制器实例、以及将接收到的UPCP数据提供到第二控制器实例的第三控制器实例。

Description

网络控制系统中的控制器

本申请是申请日为2012年10月25日、申请号为201280052475.4、名称为“用于转换通用流的机箱控制器”的发明专利申请的分案申请。

背景技术

许多当前企业具有支持各种连接、应用和系统的包括交换机、中枢节点、路由器、服务器、工作站及其他网络设备的大型并且复杂的网络。计算机联网的增加的复杂化，包括虚拟机迁移、动态工作负荷、多租期，以及特定于客户的服务质量和安全配置，要求网络控制的更好的范例。网络传统上是通过单个组件的低级别的配置来管理的。网络配置常常取决于基础网络：例如，利用访问控制列表(“ACL”)条目阻止用户的访问要求知道用户的当前IP地址。更复杂的任务要求更加详尽的网络知识：强制来宾用户的端口80流量遍历HTTP代理要求知道当前网络拓扑和每一个来宾的位置。在网络交换元件跨多个用户共享的情况下，此过程增大了困难。

作为响应，存在朝着被称为“软件定义的联网”(SDN)的新的网络控制范例的日益增长的移动。在SDN范例中，在网络中的一个或多个服务器上运行的网络控制器控制、维护，并实现控制逻辑，该控制逻辑在每个用户的基础上管辖共享的网络交换元件的转发行为。做出网络管理决策常常要求了解网络状态。为促进管理决策做出，网络控制器创建并维护网络状态的视图，并提供应用编程接口，管理应用可以通过应用编程接口访问网络状态的视图。

维护大型网络(包括数据中心和企业网络两者)的一些主要目标是可缩放性、迁移性、以及多租期。为满足这些目标中的一个所采取的许多方法导致妨碍其他目标中的至少一个。例如，可以轻松地为L2域内的虚拟机提供网络迁移性，但是L2域不能缩放到大型尺寸。此外，保持用户的隔离也大大地使迁移性复杂化。如此，需要可以满足可缩放性、迁移性以及多租期目标的改善的解决方案。

发明内容

本发明的一些实施例提供了允许通过一个或多个共享的转发元件为若干不同的用户指定若干不同的逻辑数据路径(LDP)集合而不允许不同的用户控制或者甚至查看彼此的转发逻辑的网络控制系统。这些共享的转发元件在下面被称为管理交换元件或管理转发元件，因为它们是由网络控制系统管理的，以便实现LDP集合。

在一些实施例中，网络控制系统包括允许系统从用户接受LDP集合并配置交换元件以实现这些LDP集合的一个或多个控制器(在下面也被称为“控制器实例”)。这些控制器允许系统以在共享相同的管理交换元件的同时防止不同的用户查看或控制彼此的LDP集合和逻辑网络的方式虚拟化对共享的交换元件以及由这些共享的交换元件之间的连接所定义的逻辑网络的控制。

在一些实施例中，每一个控制器实例是执行一个或多个模块的设备(例如，通用计算机)，这一个或多个模块将用户输入从逻辑控制平面(LCP)转换为逻辑转发平面(LFP)数据，然后将LFP数据转换为物理控制平面(PCP)数据。在一些实施例中，这些模块包括控制模块和虚拟化模块。控制模块允许用户指定并填充逻辑数据路径集合(LDPS)，而虚拟化模块通过将LDPS映射到物理交换基础结构来实现指定的LDPS。在一些实施例中，控制模块和虚拟化模块是两个单独的应用，而在其他实施例中，它们是同一个应用的一部分。

在一些实施例中，控制器的控制模块从用户或另一个源接收描述LDPS的LCP数据(例如，描述与逻辑交换元件相关联的连接的数据)。然后，控制模块将此数据转换为LFP数据，然后LFP数据被提供给虚拟化模块。然后，虚拟化模块从LFP数据生成PCP数据。PCP数据被传播到管理交换元件。在一些实施例中，控制模块和虚拟化模块使用nLog引擎从LCP数据生成LFP数据以及从LFP数据生成PCP数据。

一些实施例的网络控制系统使用不同的控制器来执行不同的任务。例如，在一些实施例中，网络控制系统使用三种类型的控制器。第一控制器类型是应用协议接口(API)控制器。API控制器负责通过API调用从用户接收配置数据和用户查询并对用户查询做出响应。API控制器还将接收到的配置数据传播到其他控制器。如此，一些实施例的API控制器充当用户和网络控制系统之间的接口。

第二类型的控制器是负责通过计算通用流条目来实现LDP集合的逻辑控制器，其中，通用流条目是实现LDP集合的管理交换元件的流条目的通用表示。在一些实施例中，逻辑控制器不直接与管理交换元件进行交互，而是将通用流条目推送到第三类型的控制器(物理控制器)。

不同实施例中的物理控制器具有不同的职责。在一些实施例中，物理控制器从通用流条目生成自定义流条目，并将这些自定义流条目下推送到管理交换元件。在其他实施例中，物理控制器对于特定的管理物理交换元件标识负责为特定的交换元件生成自定义流条目的第四类型的控制器(机箱控制器)，并将物理控制器从逻辑控制器接收到的通用流条目转发到机箱控制器。然后，机箱控制器从通用流条目生成自定义流条目，并将这些自定义流条目推送到管理交换元件。在另一些其他实施例中，物理控制器为一些管理交换元件生成自定义流条目，同时指示机箱控制器为其他管理交换元件生成这样的流条目。

前面的“发明内容”旨在充当本发明的一些实施例的简介。它不是本文中所公开的所有独创性的主题的介绍或概览。随后的“具体实施方式”以及在“具体实施方式”中参考的附图将进一步描述在“发明内容”中所描述的实施例以及其他实施例。相应地，为理解由此文档所描述的所有实施例，需要完整地阅读“发明内容”、“具体实施方式”以及“附图”。此外，所要求保护的主题将不受“发明内容”、“具体实施方式”以及“附图”中的说明性细节限制，而是将由所附权利要求书来定义，因为在不偏离主题的精神的情况下，所要求保护的主题可以以其他具体形式来实现。

附图说明

在所附的权利要求中阐述了本发明的新颖的特征。然而，为了说明的目的，在下面的附图中阐述了本发明的若干实施例。

图1示出了本发明的一些实施例的虚拟化网络系统。

图2示出了多用户服务器托管系统的交换机基础结构。

图3示出了管理边缘交换元件的网络控制器。

图4示出了跨一组交换元件实现的多个逻辑交换元件的示例。

图5示出了控制管理交换元件的指令通过控制器实例的各种处理层的传播。

图6示出了一些实施例的多实例、分布式网络控制系统。

图7示出了为交换元件指定主控控制器实例的示例。

图8示出了多个控制器实例的示例操作。

图9在概念上示出了输入转换应用的软件体系结构。

图10示出了本发明的一些实施例的控制应用。

图11示出了本发明的一些实施例的虚拟化应用。

图12在概念上示出了RE输出表中的不同的表。

图13示出了本发明的一些实施例的控制应用和虚拟化应用的表映射操作的简化视图。

图14示出了集成的应用的示例。

图15示出了集成的应用的另一示例。

图16在概念上示出了网络控制系统的示例体系结构。

图17在概念上示出了网络控制系统的示例体系结构。

图18示出了机箱控制应用的示例体系结构。

图19示出了基于通用物理控制平面数据在两个管理交换元件之间的隧道的示例创建。

图20在概念上示出了一些实施例所执行的从通用物理控制平面数据生成自定义物理控制平面数据的处理。

图21在概念上示出了一些实施例所执行的生成自定义隧道流指令并向管理交换元件发送自定义指令的处理。

图22在概念上以七个不同的阶段示出了将通用隧道流指令转换为自定义指令的机箱控制器的示例操作。

图23在概念上示出了用来实现本发明的一些实施例的电子系统。

具体实施方式

在下面的对本发明的详细描述中，阐述并描述了很多细节、示例、以及本发明的各实施例。然而，对本领域技术人员来说清楚的是，本发明不仅限于阐述的实施例，可以在没有所讨论的一些具体细节和示例的情况下实施本发明。

本发明的一些实施例提供了允许通过一个或多个共享的转发元件为若干不同的用户指定若干不同的LDP集合而不允许不同的用户控制或者甚至查看彼此的转发逻辑的网络控制系统。在一些实施例中，共享的转发元件可包括虚拟或物理网络交换机、软件交换机(例如，Open vSwitch)、路由器、和/或其他交换设备，以及在这些交换机、路由器，和/或其他交换设备之间建立连接的任何其他网络元件(诸如负载均衡器等等)。这样的转发元件(例如，物理交换机或路由器)在下面也被称为交换元件。与现成的交换机相比，在一些实施例中，软件转发元件是通过将其交换表以及逻辑存储在独立设备(例如，独立计算机)的存储器中而形成的交换元件，而在其他实施例中，软件转发元件是通过将其交换表以及逻辑存储在还执行系统管理程序和在该系统管理程序上面的一个或多个虚拟机的设备(例如，计算机)的存储器中而形成的交换元件。

这些管理的、共享的交换元件在下面被称为管理交换元件或管理转发元件，因为它们是由网络控制系统管理的，以便实现LDP集合。在一些实施例中，控制系统通过将PCP数据推送到这些交换元件来管理这些交换元件，如下面所进一步描述的。交换元件一般接收数据(例如，数据包)并对数据执行一个或多个处理操作，诸如丢弃接收到的数据包，将从一个源设备接收到的数据包传递到另一个目的地设备，处理数据包、然后将其传给目的地设备等等。在一些实施例中，被推送到交换元件的PCP数据由交换元件(例如，由交换元件的通用处理器)转换为物理转发平面数据，该物理转发平面数据指定交换元件(例如，交换元件的专门的交换电路)如何处理交换元件接收到的数据包。

在一些实施例中，网络控制系统包括允许系统从用户接受LDP集合并配置交换元件以实现这些LDP集合的一个或多个控制器(在下面也被称为“控制器实例”)。这些控制器允许系统以在共享相同的管理交换元件的同时防止不同的用户查看或控制彼此的LDP集合和逻辑网络的方式虚拟化对共享的交换元件以及由这些共享的交换元件之间的连接所定义的逻辑网络的控制。

在一些实施例中，每一个控制器实例是执行一个或多个模块的设备(例如，通用计算机)，这一个或多个模块将用户输入从LCP转换为LFP，然后将LFP数据转换为PCP数据。在一些实施例中，这些模块包括控制模块和虚拟化模块。控制模块允许用户指定并填充LDPS，而虚拟化模块通过将LDPS映射到物理交换基础结构来实现指定的LDPS。在一些实施例中，控制模块和虚拟化模块按照被写入到关系数据库数据结构中的记录来表达指定的或映射的数据。即，关系数据库数据结构存储通过控制模块接收到的逻辑数据路径输入和逻辑数据路径输入被虚拟化模块映射到的物理数据。在一些实施例中，控制应用和虚拟化应用是两个单独的应用，而在其他实施例中，它们是同一个应用的一部分。

上文描述了网络控制系统的若干示例。下面将描述若干比较详细的实施例。第I部分描述了一些实施例的网络控制系统。第II部分描述了由网络控制系统执行的通用转发状态转换。第III部分描述了用来实现本发明的一些实施例的电子系统。

I.网络控制系统

A.用于将流推送到控制层的外层

图1示出了本发明的一些实施例的虚拟化网络系统100。此系统允许多个用户创建并控制网络基础结构交换元件(例如，交换机、虚拟交换机、软件交换机等等)的共享集合上的多个不同的LDP集合。在允许用户创建并控制用户的逻辑数据路径(LDP)集合(即，用户的交换逻辑)时，系统不允许用户对另一个用户的LDP集合进行直接访问以便查看或修改其他用户的交换逻辑。然而，系统确实允许不同的用户通过它们的虚拟化交换逻辑向彼此传递数据包，如果用户需要这样的通信。

如图1所示，系统100包括一个或多个交换元件105和网络控制器110。交换元件包括构成系统100的网络基础结构交换元件的N个交换设备(其中，N是等于1或更大的数字)。在一些实施例中，网络基础结构交换元件包括虚拟或物理网络交换机、软件交换机(例如，Open vSwitch)、路由器、和/或其他交换设备，以及在这些交换机、路由器、和/或其他交换设备之间建立连接的任何其他网络元件(诸如负载均衡器等等)。所有这样的网络基础结构交换元件在下面被称为交换元件或转发元件。

虚拟或物理交换设备105通常包括控制交换逻辑125和转发交换逻辑130。在一些实施例中，交换机的控制逻辑125指定(1)要应用于传入数据包的规则，(2)要被丢弃的数据包，以及(3)将应用于传入数据包的数据包处理方法。虚拟或物理交换元件105使用控制逻辑125来填充管辖转发逻辑130的表。转发逻辑130对传入数据包执行查询操作，并将传入数据包转发到目的地地址。

如在图1中进一步示出的，网络控制器110包括控制应用115，其中，(例如，由一个或多个管理员或用户)通过控制应用115按照LDP集合为一个或多个用户指定交换逻辑。网络控制器110还包括虚拟化应用120，该虚拟化应用120将LDP集合转换为控制交换逻辑以便被推送到交换设备105。在此申请中，对于一些实施例，控制应用和虚拟化应用被称为“控制引擎”和“虚拟化引擎”。

在一些实施例中，虚拟化系统100包括一个以上的网络控制器110。网络控制器包括逻辑控制器，每一个逻辑控制器负责为特定LDPS的一组交换设备指定控制逻辑。网络控制器还包括物理控制器，每一个物理控制器将控制逻辑推送到由该物理控制器负责管理的一组交换元件。换言之，逻辑控制器只为实现特定LDPS的一组交换元件指定控制逻辑，而物理控制器将控制逻辑推送到由物理控制器管理的交换元件，而不管交换元件实现的LDP集合是什么。

在一些实施例中，网络控制器的虚拟化应用使用关系数据库数据结构按照数据记录(例如，数据元组)存储由虚拟化应用跟踪的交换机元件状态的副本。这些数据记录表示所有物理或虚拟交换元件及其在物理网络拓扑内的互连以及它们的转发表的图。例如，在一些实施例中，网络基础结构内的每一个交换元件都由关系数据库数据结构中的一个或多个数据记录来表示。然而，在其他实施例中，虚拟化应用的关系数据库数据结构只存储有关一些交换元件的状态信息。例如，如下面所进一步描述的，在一些实施例中，虚拟化应用只跟踪在网络基础结构边缘处的交换元件。在另一些其他实施例中，虚拟化应用存储有关网络中的边缘交换元件以及网络中的促进边缘交换元件之间的通信的一些非边缘交换元件的状态信息。

在一些实施例中，关系数据库数据结构是虚拟化的网络系统100中的控制模型的心脏。根据一种方法，应用通过读写关系数据库数据结构来控制网络。具体而言，在一些实施例中，应用控制逻辑可以(1)读取与关系数据库数据结构中的网络实体记录相关联的当前状态，以及(2)通过对这些记录进行操作来改变网络状态。根据此模型，当虚拟化应用120需要修改交换元件105的表(例如，控制平面流表)中的记录时，虚拟化应用120首先写入表示关系数据库数据结构中的表的一个或多个记录。然后，虚拟化应用传播对交换元件的表的该更改。

在一些实施例中，控制应用还使用关系数据库数据结构来存储每一个用户指定的LDPS的逻辑配置和逻辑状态。在这些实施例中，关系数据库数据结构中的表示实际交换元件的状态的信息只反映存储在关系数据库数据结构中的全部信息的子集。

在一些实施例中，控制应用和虚拟化应用使用辅助数据结构来存储用户指定的LDPS的逻辑配置和逻辑状态。在这些实施例中，此辅助数据结构充当不同的网络控制器之间的通信介质。例如，当用户使用不负责特定LDPS的逻辑控制器来指定该特定LDPS时，逻辑控制器通过这些逻辑控制器的辅助数据结构，将特定LDPS的逻辑配置传递到负责该特定LDPS的另一个逻辑控制器。在一些实施例中，从用户接收特定LDPS的逻辑配置的逻辑控制器将配置数据传递到虚拟化的网络系统中的所有其他控制器。如此，在一些实施例中，每个逻辑控制器中的辅助存储器结构包括所有用户的所有LDP集合的逻辑配置数据。

在一些实施例中，控制器实例的操作系统(未示出)为不同实施例的控制应用和虚拟化应用和交换元件105提供一组不同的通信构造(未示出)。例如，在一些实施例中，操作系统向管理交换元件提供交换元件105和虚拟化应用120之间的通信接口(未示出)，其中(1)交换元件105为任何一个用户执行物理交换，以及(2)虚拟化应用120用于将用户的交换逻辑推送到交换元件。在这些实施例中的一些中，虚拟化应用通过通常已知的交换访问接口来管理交换元件的控制交换逻辑125，其中，该交换访问接口指定用于允许外部应用(诸如虚拟化应用)控制交换元件的控制平面功能的一组API。具体而言，管理交换元件通信接口实现这组API，以便虚拟化应用可以使用管理交换元件通信接口将存储在关系数据库数据结构中的记录发送到交换元件。

这样的已知的交换访问接口的两个示例是开放流(OpenFlow)接口以及“开放虚拟交换”通信接口，在下面的两篇文章中分别进行了描述：McKeown,N.(2008).OpenFlow:Enabling Innovation in Campus Networks(可以从http://www.openflowswitch.org//documents/openflow-wp-latest.pdf中检索到)以及Pettit,J.(2010).VirtualSwitching in an Era of Advanced Edges(可以从http://openvswitch.org/papers/dccaves2010.pdf中检索到)。这两篇文章以引用的方式并入本文中。

应当注意，对于上文以及下文所描述的使用关系数据库数据结构存储数据记录的那些实施例，可以可替选地或结合地使用可以以面向对象的数据对象的形式存储数据的数据结构。这样的数据结构的示例是NIB数据结构。在2011年7月6日提交的美国专利申请13/177,529以及13/177,533中描述了使用NIB数据结构的多个示例。美国专利申请13/177,529和13/177,533以引用的方式并入本文中。

图1通过控制交换逻辑125周围的晕圈135的描绘在概念上示出了交换访问API的使用。通过这些API，虚拟化应用可以读写控制平面流表中的条目。在一些实施例中，虚拟化应用与交换元件的控制平面资源(例如，控制平面表)的连接是在带内实现的(即，利用由操作系统控制的网络流量)，而在其他实施例中，它是在带外实现的(即，通过单独的物理网络)。对于超出集中于故障和与操作系统的基本连接以外的选择的机制，只有最低要求，如此，当使用单独的网络时，诸如IS-IS或OSPF之类的标准IGP协议就足够了。

当交换元件是物理交换元件(而不是软件交换元件)时，为了定义交换元件的控制交换逻辑125，一些实施例的虚拟化应用使用“开放虚拟交换”协议创建交换元件的控制平面内的一个或多个控制表。控制平面通常是由交换元件的通用CPU创建和执行的。一旦系统创建了控制表，虚拟化应用就使用开放流协议向控制表写入流条目。物理交换元件的通用CPU使用其内部逻辑来转换被写入到控制表中的条目，以填充交换元件的转发平面中的一个或多个转发表。转发表通常是由交换元件的专门的交换芯片创建和执行的。通过转发表内的流条目的执行，交换元件的交换芯片可以处理和路由其接收到的数据的数据包。

在一些实施例中，除逻辑和物理控制器之外，虚拟化的网络系统100还包括机箱控制器。在这些实施例中，机箱控制器实现交换访问API以管理特定交换元件。即，机箱控制器将控制逻辑推送到特定交换元件。在这些实施例中，物理控制器充当将控制逻辑从逻辑控制器中继到机箱控制器的聚合点，该机箱控制器连接由物理控制器负责的交换元件集合。物理控制器将控制逻辑分发到管理交换元件集合的机箱控制器。在这些实施例中，网络控制器的操作系统的管理交换元件通信接口在物理控制器和机箱控制器之间建立通信信道(例如，远程过程调用(RPC)信道)，使得物理控制器可以将作为数据记录存储在关系数据库数据结构中的控制逻辑发送到机箱控制器。机箱控制器又会使用交换访问API或其他协议将控制逻辑推送到交换元件。

一些实施例的操作系统提供的通信构造还包括导出器(未示出)，网络控制器可以使用导出器将数据记录发送到另一个网络控制器(例如，从一个逻辑控制器到另一个逻辑控制器，从一个物理控制器到另一个物理控制器，从一个逻辑控制器到一个物理控制器，从一个物理控制器到一个逻辑控制器，等等)。具体而言，网络控制器的控制应用和虚拟化应用可以使用导出器，将存储在关系数据库数据结构中的数据记录导出到一个或多个其他网络控制器。在一些实施例中，导出器在两个网络控制器之间建立通信信道(例如，RPC信道)，以便一个网络控制器可以通过该信道将数据记录发送到另一个网络控制器。

一些实施例的操作系统还提供导入器，网络控制器可以使用导入器从网络控制器接收数据记录。一些实施例的导入器充当另一个网络控制器的导出器的对应物。即，导入器位于在两个网络控制器之间建立的通信信道的接收端。在一些实施例中，网络控制器遵循发布-预订模型，其中，接收方控制器预订信道以仅从提供接收方控制器感兴趣的数据的网络控制器接收数据。

B.将流推送到边缘交换元件

如上文所提及的，在一些实施例中，关系数据库数据结构存储关于系统的网络基础结构内的每一个交换元件的数据，而在其他实施例中，关系数据库数据结构仅存储有关网络基础结构的边缘处的交换元件的状态信息。图2和图3示出了区别这两种不同方法的示例。具体而言，图2示出了多用户服务器托管系统的交换基础结构。在此系统中，使用六个交换元件来互连两个用户A和B的六台机器。这些交换元件205-220中的四个是与用户A和B的机器235-260具有直接连接的边缘交换元件，而交换元件225和230中的两个是互连边缘交换元件并彼此连接的内部交换元件(即，非边缘交换元件)。在一些实施例中，上文以及下文所描述的图中所示出的所有交换元件都可以是软件交换元件，而在其他实施例中，交换元件是软件和物理交换元件的混合。例如，在一些实施例中，边缘交换元件205-220以及非边缘交换元件225-230是软件交换元件。此外，本申请中所描述的“机器”还包括虚拟机和诸如计算设备之类的物理机器。

图3示出了管理边缘交换元件205-220的网络控制器300。网络控制器300类似于上文参考图1所描述的网络控制器110。如图3所示，控制器300包括控制应用305和虚拟化应用310。控制器实例300的操作系统维护只包含关于边缘交换元件205-220的数据记录的关系数据库数据结构(未示出)。另外，在操作系统上运行的应用305和310允许用户A和B针对他们使用的边缘交换元件修改他们的交换元件配置。然后，如果需要，网络控制器300将这些修改传播到边缘交换元件。具体而言，在此示例中，两个边缘交换元件205和220被用户A和B的机器使用，而边缘交换元件210只供用户A的机器245使用并且边缘交换元件215只供用户B的机器250使用。相应地，图3示出了网络控制器300修改交换元件205和220中的用户A和B记录，但是只更新交换元件210中的用户A记录以及只更新交换元件215中的用户B记录。

由于若干原因，一些实施例的控制器300只控制边缘交换元件(即，只在关系数据库数据结构中维护关于边缘交换元件的数据)。控制边缘交换元件向控制器提供了用于在机器(例如，计算设备)之间维持隔离(这是需要的)而不是在所有交换元件之间维持隔离(这是不需要的)的足够的机制。内部交换元件在交换元件之间转发数据包。边缘交换元件在机器和其他网络元件(例如，其他交换元件)之间转发数据包。如此，控制器可以简单地通过控制边缘交换元件来维持用户隔离，这是因为边缘交换元件是将数据包转发到机器的管线中的最后一个交换元件。

除控制边缘交换元件之外，一些实施例的网络控制器还使用并控制插入在交换网络层次结构中的非边缘交换元件以简化和/或促进被控制的边缘交换元件的操作。例如，在一些实施例中，控制器要求其控制的交换元件在分层交换体系结构中被互连，该分层交换体系结构具有若干边缘交换元件作为叶子节点以及具有一个或多个非边缘交换元件作为非叶子节点。在一些这样的实施例中，每一个边缘交换元件都连接到非叶子交换元件中的一个或多个，并使用这样的非叶子交换元件来促进其与其他边缘交换元件的通信。

上面的讨论涉及由一些实施例的网络控制器对边缘交换元件和非边缘交换元件进行的控制。在一些实施例中，边缘交换元件和非边缘交换元件(叶子节点和非叶节点)可被称为管理交换元件。这是因为，这些交换元件是由网络控制器管理的(而不是网络中的不由网络控制器管理的非管理交换元件)，以便通过管理交换元件实现LDP集合。

一些实施例的网络控制器基于上文所描述的物理数据和逻辑数据，跨管理交换元件实现逻辑交换元件。逻辑交换元件(也被称为“逻辑转发元件”)可以被定义为以交换元件可以采用的任意数量的不同的方式起作用(例如，层2交换、层3路由等等)。网络控制器通过对管理交换元件的控制来实现定义的逻辑交换元件。在一些实施例中，网络控制器跨管理交换元件实现多个逻辑交换元件。这允许跨管理交换元件实现多个不同的逻辑交换元件，而不考虑网络的网络拓扑。

一些实施例的管理交换元件可以被配置成基于不同的路由准则来路由网络数据。如此，可以控制通过网络中的交换元件的网络数据流，以便跨管理交换元件实现多个逻辑交换元件。

C.逻辑交换元件和物理交换元件

图4示出了跨一组交换元件实现的多个逻辑交换元件的示例。具体而言，图4在概念上示出了跨管理交换元件410-430实现的逻辑交换元件480和490。如图4所示，网络400包括管理交换元件410-430和机器440-465。如此图所示出的，机器440、450和460属于用户A，而机器445、455和465属于用户B。

一些实施例的管理交换元件410-430在耦合到管理交换元件410-430的网络中的网络元件之间路由网络数据(例如，数据包、帧等等)。如图所示，管理交换元件410在机器440、445和交换元件420之间路由网络数据。类似地，交换元件420在机器450和管理交换元件410、430之间路由网络数据，而交换元件430在机器455-465和交换元件420之间路由网络数据。

此外，管理交换元件410-430中的每一个基于交换机的转发逻辑(在一些实施例中，采用表的形式)来路由网络数据。在一些实施例中，转发表根据路由准则来确定向哪里路由网络数据(例如，交换机上的端口)。例如，层2交换元件的转发表可以基于MAC地址(例如，源MAC地址和/或目的地MAC地址)来确定向哪里路由网络数据。作为另一个示例，层3交换元件的转发表可以基于IP地址(例如，源IP地址和/或目的地IP地址)来确定向哪里路由网络数据。许多其他类型的路由准则也是可以的。

如图4所示，管理交换元件410-430中的每一个中的转发表包括若干记录。在一些实施例中，每一个记录都指定用于基于路由准则来路由网络数据的操作。在一些实施例中，记录可以被称为流条目，因为记录通过管理交换元件410-430来控制数据“流”。

图4还示出了每一个用户的逻辑网络的概念表示。如图所示，用户A的逻辑网络480包括用户A的机器440、450和460所耦合到的逻辑交换元件485。用户B的逻辑网络490包括用户B的机器445、455和465所耦合到的逻辑交换元件495。如此，从用户A的角度来看，用户A具有只有用户A的机器所耦合到的交换元件，而从用户B的角度来看，用户B具有只有用户B的机器所耦合到的交换元件。换言之，对于每一个用户，用户具有其自己的只包括该用户的机器的网络。

下面将描述用于实现源自机器440并发往机器450以及源自机器440并发往机器460的网络数据流的概念流条目。管理交换元件410的转发表中的流条目“A1到A2”指示管理交换元件410将源自机器410并发往机器450的网络数据路由到交换元件420。交换元件420的转发表中的流条目“A1到A2”指示交换元件420将源自机器410并发往机器450的网络数据路由到机器450。因此，当机器440发送要发往机器450的网络数据时，管理交换元件410和420基于交换元件的转发表中的对应的记录，沿着数据路径470来路由网络数据。

此外，管理交换元件410的转发表中的流条目“A1到A3”还指示管理交换元件440将源自机器440并发往机器460的网络数据路由到交换元件420。交换元件420的转发表中的流条目“A1到A3”指示交换元件420将源自机器440并发往机器460的网络数据路由到交换元件430。交换元件430的转发表中的流条目“A1到A3”指示交换元件430将源自机器440并发往机器460的网络数据路由到机器460。如此，当机器440发送要发往机器460的网络数据时，管理交换元件410-430基于交换元件的转发表中的对应的记录，沿着数据路径470和475来路由网络数据。

尽管上文描述了用于路由源自机器440并发往机器450以及源自机器440并发往机器460的网络数据的概念流条目，但是，类似的流条目将被包括用于在用户A的逻辑网络480中的其他机器之间路由网络数据的管理交换元件410-430的转发表中。此外，类似的流条目将被包括在用于在用户B的逻辑网络490中的机器之间路由网络数据的管理交换元件410-430的转发表中。

如图4所示的概念流条目包括管理交换元件的源和目的地信息以弄清楚数据包要被发送到的下一跳交换元件。然而，源信息不必在流条目中，因为一些实施例的管理交换元件可以只使用目的地信息(例如，上下文标识符、目的地地址等等)即可弄清楚下一跳交换元件。

在一些实施例中，由隧道协议(例如，无线接入点的控制和配置(CAPWAP)、通用路由封装(GRE)、GRE因特网协议安全(IPsec)等等)所提供的隧道可以用来促进跨管理交换元件410-430的逻辑交换元件485和495的实现。通过隧道化，将一个数据包作为另一个数据包的有效负载，通过交换机和路由器进行传输。即，隧道化的数据包不必暴露其地址(例如，源和目的地MAC地址)，因为该数据包是基于对隧道化的数据包进行封装的外数据包的标头中所包括的地址而转发的。因此，隧道化可以将逻辑地址空间与物理地址空间分离，因为隧道化的数据包可以具有在逻辑地址空间中有意义的地址，而外数据包是基于物理地址空间中的地址被转发/路由的。如此，隧道可以被视为连接网络中的管理交换元件以便实现逻辑交换元件485和495的“逻辑线路”。

以上文所描述的各种方式来配置交换元件以跨一组交换元件实现多个逻辑交换元件，从每一个用户的角度来看，允许多个用户中的每一个都具有单独的网络和/或交换元件，而事实上用户共享相同的一组交换元件和/或这一组交换元件之间的连接(例如，隧道、物理线路)中的一些或全部。

II.通用转发状态

A.控制器实例的层

图5示出了控制管理交换元件的指令通过本发明的一些实施例的控制器实例的各种处理层的传播。此图示出了控制数据管线500，该控制数据管线500转换控制平面数据，并通过相同或不同的控制器实例的四个处理层，将控制平面数据传播到管理交换元件525。这四层是输入转换层505、控制层510、虚拟化层515，以及自定义层520。

在一些实施例中，这四层处于相同的控制器实例中。然而，在其他实施例中，存在这些层的其他布置。例如，在其他实施例中，只有控制层和虚拟化层510和515处于相同的控制器实例中，但是传播自定义物理控制平面(CPCP)数据的功能驻留在另一个控制器实例(例如，机箱控制器，未示出)的自定义层中。在这些其他实施例中，将通用物理控制平面(UPCP)数据从一个控制器实例的关系数据库数据结构(未示出)传输到另一个控制器实例的关系数据库数据结构，然后，此另一个控制器实例生成CPCP数据，并将CPCP数据推送到管理交换元件。前一控制器实例可以是生成UPCP数据的逻辑控制器，而后一控制器实例可以是将UPCP数据自定义为CPCP数据的物理控制器或机箱控制器。

如图5所示，在一些实施例中，输入转换层505具有可以用来表达此层的输出的LCP530。在一些实施例中，应用(例如，基于web的应用，未示出)被提供给用户，供用户提供指定LDP集合的输入。此应用按照API调用的形式将输入发送到输入转换层505，该输入转换层505将API调用转换为可以由控制层510处理的格式的LCP数据。例如，输入被转换成可以馈送给控制层的nLog表映射引擎的一组输入事件。下面将进一步描述nLog表映射引擎及其操作。

在一些实施例中，控制层510具有可以用来表达此层的输入和输出的LCP 530和LFP 535。LCP包括允许控制层及其用户为一个或多个用户指定LCP内的一个或多个LDP集合的较高级别的构造的集合。LFP 535以可以被虚拟化层515处理的格式来表示用户的LDP集合。如此，两个逻辑平面530和535是通常可以在典型的管理交换元件525中发现的控制和转发平面555和560的虚拟化空间类似物，如图5所示。

在一些实施例中，控制层510定义和暴露LCP构造，其中，层本身或层的用户利用LCP构造来定义LCP内的不同的LDP集合。例如，在一些实施例中，LCP数据530包括逻辑ACL数据等等。此数据中的一些(例如，逻辑ACL数据)可以由用户指定，而其他这样的数据(例如，逻辑L2或L3记录)是由控制层所生成的，并且不可以由用户指定。在一些实施例中，控制层510响应于由控制层510检测到的对关系数据库数据结构的某些更改(指示对管理交换元件和管理数据路径的更改)，生成和/或指定这样的数据。

在一些实施例中，可以初始地指定LCP数据(即，按照控制平面构造表达的LDP集合数据)，而不考虑来自管理交换元件的当前操作数据，以及不考虑此控制平面数据将被转换为PCP数据的方式。例如，LCP数据可以指定连接五个计算机的一个逻辑交换元件的控制数据，尽管此控制平面数据以后可以被转换为在五个计算机之间实现期望交换的三个管理交换元件的物理控制数据。

控制层包括用于将LCP内的任何LDPS转换为LFP 535中的LDPS的一组模块(未示出)。在一些实施例中，控制层510使用nLog表映射引擎来执行此转换。下面进一步描述了控制层510使用nLog表映射引擎来执行此转换。控制层还包括用于将LDP集合从控制层510的LFP 535推送到虚拟化层515的LFP 540的一组模块(未示出)。

LFP 540包括一个或多个用户的一个或多个LDP集合。在一些实施例中，LFP 540包括一个或多个用户的一个或多个LDP集合的逻辑转发数据。此数据中的一些被控制层推送到LFP 540，而其他这样的数据被用于检测关系数据库数据结构中的事件的虚拟化层推送到LFP，如下面针对一些实施例进一步描述的。

除LFP 540之外，虚拟化层515还包括UPCP 545。UPCP 545包括LDP集合的UPCP数据。虚拟化层包括用于将LFP 540内的任何LDP集合转换为UPCP 535中的UPCP数据的一组模块(未示出)。在一些实施例中，虚拟化层515使用nLog表映射引擎来执行此转换。虚拟化层还包括用于将UPCP数据从虚拟化层515的UPCP 545推送到自定义层520的关系数据库数据结构的一组模块(未示出)。

在一些实施例中，被发送到自定义层515的UPCP数据允许管理交换元件525根据由控制层510所指定的LDP集合来处理数据包。然而，与CPCP数据相比，UPCP数据不是由控制层所指定的逻辑数据的完整实现，因为在一些实施例中，UPCP数据不表示管理交换元件的差异和/或管理交换元件的特定于位置的信息。

对于每一个管理交换元件，UPCP数据必须被转换为CPCP数据，以便在管理交换元件处完全实现LDP集合。例如，当LDP集合指定横跨若干管理交换元件的隧道时，UPCP数据使用表示隧道的一端的管理交换元件的特定网络地址(例如，IP地址)来表示隧道的该端。然而，隧道横跨的其他管理交换元件中的每一个使用管理交换元件本地的端口号来引用具有特定网络地址的末端管理交换元件。即，特定网络地址必须被转换为每一个管理交换元件的本地端口号，以便完全实现用于指定管理交换元件处的隧道的LDP集合。

作为要被转换为CPCP数据的中间数据的UPCP数据使得一些实施例的控制系统能够缩放，假设自定义层520正在不同于生成UPCP数据的控制实例的另一个控制器实例中运行。这是因为，虚拟化层515不必对于实现LDP集合的每一个管理交换元件，将指定LDP集合的LFP数据转换为CPCP数据。相反，对于实现LDP集合的所有管理交换元件，虚拟化层515将LFP转换为UPCP数据一次。如此，虚拟化应用节约计算资源，否则它将必须消耗计算资源以执行LDP集合到CPCP数据的转换(转换次数与实现LDP集合的管理交换元件的数量一样多)。

自定义层520包括可以用来表示此层的输入和输出的UPCP 546和CPCP 550。自定义层包括用于将UPCP 546中的UPCP数据转换为CPCP 550中的CPCP数据的一组模块(未示出)。在一些实施例中，自定义层520使用nLog表映射引擎来执行此转换。虚拟化层还包括用于将CPCP数据从自定义层520的CPCP 550推送到管理交换元件525的一组模块(未示出)。

被推送到每一管理交换元件的CPCP数据是特定于管理交换元件的。CPCP数据(尽管数据被称为“物理”数据)允许管理交换元件在物理和逻辑数据处理域执行物理交换操作。在一些实施例中，自定义层520运行在针对每一个管理交换元件525的单独的控制器实例中。

在一些实施例中，自定义层520不在控制器实例中运行。在这些实施例中，自定义层515驻留在管理交换元件525中。因此，在这些实施例中，虚拟化层515将UPCP数据发送到管理交换元件。每一个管理交换元件都将把UPCP数据自定义为特定于管理交换元件的CPCP数据。在这些实施例中的一些中，控制器守护程序将在每一个管理交换元件中运行，并将通用数据转换为管理交换元件的自定义数据。下面将进一步描述控制器守护程序。

在一些实施例中，被传播到管理交换元件525的自定义物理控制平面数据使得此交换元件能够基于在逻辑域中定义的逻辑值，对网络数据(例如，数据包)执行物理转发操作。具体而言，在一些实施例中，自定义物理控制平面数据指定包括逻辑值的流条目。这些逻辑值包括逻辑地址、逻辑端口号等等，它们用于在逻辑域中转发网络数据。这些流条目还将逻辑值映射到在物理域中定义的物理值，以便管理交换元件可以通过基于逻辑值执行物理转发操作，对网络数据执行逻辑转发操作。如此，物理控制平面数据促进实现跨管理交换元件的逻辑交换元件。在2011年7月6日提交的美国专利申请13/177,535中进一步描述了使用传播的物理控制平面数据在管理交换元件中实现逻辑数据处理的若干示例。美国专利申请13/177,535以引用的方式并入本文中。

由控制数据管线500的层处理的控制平面数据随着层越高而变得更全局。即，控制层510中的逻辑控制平面数据将横跨用于实现由逻辑控制平面数据所定义的逻辑交换元件的整组管理交换元件。相比之下，自定义层520中的自定义物理控制平面数据是本地的，并且特定于用于实现逻辑交换元件的每一个管理交换元件。

B.多控制器实例

图6示出了一些实施例的多实例、分布式网络控制系统600。此分布式系统利用三个控制器实例605、610和615，控制多个交换元件690。在一些实施例中，分布式系统600允许不同的控制器实例控制同一个交换元件或不同的交换元件的操作。如图6所示，每一个实例都包括输入模块620、控制模块625、记录635、辅助存储器结构(例如，PTD)640、控制器间的通信接口645、管理交换元件通信接口650。

控制器实例的输入模块620与上文参考图5所描述的输入转换层505的类似之处在于，输入模块620从用户获取输入，并将输入转换为控制模块625可理解和处理的LCP数据。如上文所提及的，在一些实施例中，输入采用API调用的形式。输入模块620将LCP数据发送到控制模块625。

控制器实例的控制模块625与控制层510的类似之处在于，控制模块625将LCP数据转换为LFP数据，并将LFP数据推送到虚拟化模块630中。另外，控制模块625判断接收到的LCP数据是否是控制器实例正在管理的LDPS的。如果控制器实例是LCP数据的LDPS的主控(即，管理LDPS的逻辑控制器)，则控制器实例的虚拟化模块将进一步处理数据。否则，一些实施例的控制模块625将LCP数据存储到辅助存储器640中。

控制器实例的虚拟化模块630与虚拟化层515的类似之处在于，虚拟化模块630将LFP数据转换为UPCP数据。然后，一些实施例的虚拟化模块630通过控制器之间的通信接口645，将UPCP数据发送到另一控制器实例，或通过管理交换元件通信接口650发送到管理交换元件。

当另一个控制器实例是负责管理用于实现LDPS的管理交换元件中的至少一个的物理控制器时，虚拟化模块630将UPCP数据发送到另一实例。这是当控制器实例只是负责特定LDPS的逻辑控制器而不是负责用于实现LDPS的管理交换元件的物理控制器或机箱控制器时的情况，其中，虚拟化模块630在该控制器实例上生成UPCP数据。

当管理交换元件被配置成将UPCP数据转换为特定于管理交换元件的CPCP数据时，虚拟化模块630将UPCP数据发送到管理交换元件。在此情况下，控制器实例将不会具有可执行从UPCP数据到CPCP数据的转换的自定义层或模块。

在一些实施例中，记录635是存储在控制器实例的关系数据库数据结构中的一组记录。在一些实施例中，输入模块、控制模块、以及虚拟化模块中的一些或全部使用、更新并管理存储在关系数据库数据结构中的记录。即，这些模块的输入和/或输出存储在关系数据库数据结构中。

在一些实施例中，系统600在每一个实例的关系数据库数据结构中维护相同的交换元件数据记录，而在其他实施例中，系统600允许不同实例的关系数据库数据结构基于每一个控制器实例正在管理的LDPS来存储交换元件数据记录的不同集合。

一些实施例的PTD 640是用于存储用户指定的网络配置数据(例如，按照API调用的形式从输入转换的LCP数据)的辅助存储器结构。在一些实施例中，每一个控制器实例的PTD存储使用系统600的所有用户的配置数据。在这些实施例中，接收到用户输入的控制器实例将配置数据传播到其他控制器实例的PTD，以便每个控制器实例的每个PTD都具有所有用户的所有配置数据。然而，在其他实施例中，控制器实例的PTD只存储控制器实例正在管理的特定LDPS的配置数据。

通过允许不同的控制器实例存储相同或重叠的配置数据和/或辅助存储器结构记录，系统通过防止由于任何网络控制器的故障(或关系数据库数据结构实例和/或辅助存储器结构实例的故障)所导致的数据的损失，改善其整体灵活性。例如，跨控制器实例来复制PTD使得发生故障的控制器实例能快速地从另一实例重新加载其PTD。

控制器间的通信接口645用于(例如，由导出器，未示出)与另一控制器实例建立通信信道(例如，RPC信道)。如图所示，控制器间的通信接口促进不同的控制器实例605-615之间的数据交换。

如上文所提及的，管理交换元件通信接口650促进控制器实例和管理交换元件之间的通信。在一些实施例中，管理交换元件通信接口用于将由虚拟化模块630所生成的UPCP数据传播到能够将通用数据转换为自定义数据的每一个管理交换元件。

对于分布式控制器实例之间的通信的一些或全部，系统600使用协调管理器(CM)655。每一个实例中的CM 655允许实例协调某些活动与其他实例。不同的实施例使用CM来协调实例之间的不同组的活动。这样的活动的示例包括写入到关系数据库数据结构、写入到PTD、控制交换元件、促进与控制器实例的容错有关的控制器间的通信等等。此外，CM用来寻找LDPS的主控和管理交换元件的主控。

如上文所提及的，系统600的不同的控制器实例可以控制同一个交换元件或不同的交换元件的操作。通过在若干实例上分发对这些操作的控制，系统可以容易地进行扩展以处理额外的交换元件。具体而言，系统可以将对不同的交换元件的管理分发到不同的控制器实例，以便享受可以通过使用多个控制器实例实现的高效的益处。在这样的分布式系统中，每一个控制器实例都可以具有减少的处于管理下的交换元件，由此减少了每一个控制器需要执行以生成并分发跨交换元件的流条目所需的计算数量。在其他实施例中，多个控制器实例的使用使得能够创建横向扩展网络管理系统。如何最好地在大型网络中分发网络流表的计算是CPU密集的任务。通过在多个控制器实例上拆分处理，系统600可以使用一组更多但是功能不太强大的计算机系统来创建能够处理大型网络的横向扩展网络管理系统。

为了分发工作负荷并避免来自不同的控制器实例的冲突操作，一些实施例的系统600指定系统600内的一个控制器实例(例如，605)作为LDPS和/或任何给定管理交换元件的主控(即，作为逻辑控制器或物理控制器)。在一些实施例中，每一个主控控制器实例都在其关系数据库数据结构中只存储与主控正在处理的管理交换元件有关的数据。

如上文所指出的，在一些实施例中，CM促进与控制器实例的容错有关的控制器间的通信。例如，CM通过上文所描述的辅助存储器来实现控制器间的通信。控制系统中的控制器实例可能会由于任意数量的原因而发生故障(例如，硬件故障、软件故障、网络故障等等)。不同的实施例可以使用不同的技术来判断控制器实例是否发生故障。在一些实施例中，使用一致性协议来判断控制系统中的控制器实例是否发生故障。虽然这些实施例中的一些可以使用Apache Zookeeper来实现一致性协议，但是其他实施例可以以其他方式实现一致性协议。

CM 655的一些实施例可以使用定义的超时来判断控制器实例是否发生故障。例如，如果控制器实例的CM在时间量(即，定义的超时量)内没有对通信做出响应(从控制系统中的另一控制器实例的另一CM发送的)，则判断非响应性的控制器实例发生故障。在其他实施例中，可以使用其他技术来判断控制器实例是否发生故障。

当主控控制器实例发生故障时，需要确定LDP集合和交换元件的新主控。CM 655的一些实施例通过执行选择主控控制器实例的主控选择过程来做出这样的判断(例如，用于分割对LDP集合的管理和/或分割对交换元件的管理)。一些实施例的CM 655可以执行用于为LDP集合和交换元件(其发生故障的控制器实例是主控)选择新主控控制器的主控选择过程。然而，其他实施例的CM 655可以执行(1)用于为其发生故障的控制器实例是主控的LDP集合选择新主控控制器实例的主控选择过程，以及(2)用于为其发生故障的控制器实例是主控的交换元件选择新主控控制器实例的另一主控选择过程。在这些情况下，CM 655可以确定两个不同的控制器实例作为新的控制器实例：一个用于其发生故障的控制器实例是主控的LDP集合，另一个用于其发生故障的控制器实例是主控的交换元件。

可替选地或结合地，一些实施例的集群中的控制器运行一致性算法来确定如上文所提及的主导控制器。主导控制器通过为特定工作项目指定主控控制器，分割集群中的每一个控制器实例负责的任务，而在一些情况下，在主控控制器发生故障的情况下，热待机的控制器接管。

在一些实施例中，当控制器实例被添加到控制系统中时，主控选择过程进一步用于分割对LDP集合的管理和/或对交换元件的管理。具体而言，当控制系统600检测到控制系统600中的控制器实例的成员资格变化时，CM 655的一些实施例执行主控选择过程。例如，当控制系统600检测到新网络控制器被添加到控制系统600时，CM 655可以执行主控选择过程，以将对LDP集合的管理和/或对交换元件的管理的一部分从现有的控制器实例重新分发到新控制器实例。然而，在其他实施例中，当控制系统600检测到新网络控制器被添加到控制系统600时，不会发生将对LDP集合的管理和/或对交换元件的管理的一部分从现有的控制器实例重新分发到新控制器实例。相反，在这些实施例中，当控制系统600检测到未分配的LDP集合和/或交换元件时，控制系统600将未分配的LDP集合和/或交换元件(例如，新LDP集合和/或交换元件或LDP集合和/或交换元件)从发生故障的网络控制器指定到新控制器实例。

C.分割对LDP集合和管理交换元件的管理

图7示出了为类似于图6的系统600的分布式系统700中的交换元件(即，物理控制器)指定主控控制器实例的示例。在此示例中，两个控制器705和710针对两个不同的用户A和B，控制三个交换元件S1、S2和S3。通过两个控制应用715和720，两个用户指定两个不同的LDP集合725和730，它们将被控制器的虚拟化应用745和750转换成同样地存储在两个控制器实例705和710的两个关系数据库数据结构755和760中的许多记录。

在图7中所示出的示例中，两个控制器705和710的两个控制应用715和720都可以修改用户A和B的交换元件S2的记录，但是，只有控制器705是此交换元件的主控。此示例示出了两个不同的情况。第一情况涉及控制器705为用户B，更新交换元件S2中的记录S2b1。第二情况涉及在控制应用720更新关系数据库数据结构760中的交换元件S2和用户A的记录S2a1之后，控制器705更新交换元件S2中的记录S2a1。在图7中所示出的示例中，此更新被从控制器710的关系数据库数据结构760路由到控制器705的关系数据库数据结构755，随后被路由到交换元件S2。

不同的实施例使用不同的技术来将对控制器实例710的关系数据库数据结构760的更改传播到控制器实例705的关系数据库数据结构755。例如，为传播此更新，在一些实施例中，控制器710的虚拟化应用750将一组记录直接发送到关系数据库数据结构755(通过使用控制器间的通信模块或导出器/导入器)。作为响应，虚拟化应用745会将对关系数据库数据结构755的更改发送到交换元件S2。

代替将关系数据库数据结构更改传播到另一个控制器实例的关系数据库数据结构，一些实施例的系统700使用其他技术来响应于来自控制应用720的请求，改变交换元件S2中的记录S2a1。例如，一些实施例的分布式控制系统使用辅助存储器结构(例如，PTD)作为不同的控制器实例之间的通信信道。在一些实施例中，跨所有实例复制PTD，并且关系数据库数据结构变化的一些或全部通过PTD存储器层，从一个控制器实例推送到另一个控制器实例。相应地，在图7中所示出的示例中，可以将对关系数据库数据结构760的更改复制到控制器710的PTD，从那里，它可以在控制器705的PTD和关系数据库数据结构755中被复制。

可以存在对如图7所示的操作序列的其他变型，因为一些实施例除指定控制器实例作为交换元件的主控之外，还指定一个控制器实例作为LDPS的主控。在一些实施例中，不同的控制器实例可以是交换元件以及关系数据库数据结构中的该交换元件的对应记录的主控，而其他实施例要求控制器实例是交换元件以及关系数据库数据结构中的该交换元件的所有记录的主控。

在系统700允许为交换元件以及关系数据库数据结构记录指定主控的实施例中，图7中所示出的示例示出了控制器实例710是关系数据库数据结构记录S2a1的主控，而控制器实例705是交换元件S2的主控的情况。如果除控制器实例705和710以外的控制器实例是关系数据库数据结构记录S2a1的主控，那么来自控制应用720的对关系数据库数据结构记录修改的请求将必须被传播到该其他控制器实例。然后，该其他控制器实例将修改关系数据库数据结构记录，然后该修改将导致关系数据库数据结构755和交换元件S2通过可将该修改传播到控制器实例705的任意数量的机制来更新它们的记录。

在其他实施例中，控制器实例705可以是关系数据库数据结构记录S2a1的主控，或者控制器实例705可以是交换元件S2及其关系数据库数据结构的所有记录的主控。在这些实施例中，来自控制应用720的对关系数据库数据结构记录修改的请求必须被传播到控制器实例705，然后该控制器实例705将修改关系数据库数据结构755中的记录以及交换元件S2。

如上文所提及的，不同的实施例使用不同的技术来促进不同的控制器实例之间的通信。另外，不同的实施例以不同的方式来实现控制器实例。例如，在一些实施例中，控制应用(例如，图6和7中的625或715)和虚拟化应用(例如，630或745)的堆栈(stack)安装在单一计算机上并在其中运行。此外，在一些实施例中，多个控制器实例还可以安装在单一计算机上并且并行地运行。在一些实施例中，控制器实例也可以使其组件的叠层在多个计算机之间分割。例如，在一个实例内，控制应用(例如，625或715)可以位于第一物理或虚拟机上，而虚拟化应用(例如，630或745)可以位于第二物理或虚拟机上。

图8示出了充当用于分发输入的控制器、LDPS的主控控制器(也被称为逻辑控制器)、以及管理交换元件的主控控制器(也被称为物理控制器)的若干控制器实例的示例操作。在一些实施例中，不是每一个控制器实例都包括如上文参考图6所描述的不同的模块和接口的完全的堆栈。或者，也不是每一个控制器实例都执行完全堆栈的每一个功能。例如，图8中所示出的控制器实例805、810、以及815中没有一个具有模块以及接口的完全堆栈。

此示例中的控制器实例805是用于分发输入的控制器实例。即，一些实施例的控制器实例805按照API调用的形式从用户获取输入。通过API调用，用户可以指定对配置特定LDPS(例如，配置要在一组管理交换元件中实现的逻辑交换元件或逻辑路由器)的请求，或指定对信息查询(例如，用户的逻辑交换机的逻辑端口的网络流量统计信息)的请求。在一些实施例中，控制器实例805的输入模块820接收这些API调用并将它们转换为可以存储在PTD 825中并发送到另一个控制器实例的形式(例如，数据元组或记录)。

然后，此示例中的控制器实例805将这些记录发送到负责管理特定LDPS的记录的另一个控制器实例。在此示例中，控制器实例810负责LDPS的记录。控制器实例810从控制器实例805的PTD 825接收记录，并将记录存储到PTD 845中，该PTD 845是控制器实例810的辅助存储器结构。在一些实施例中，不同的控制器实例的PTD可以直接彼此交换信息，并且不必依赖于控制器间的通信接口。

然后，控制应用810检测这些记录向PTD的添加，并处理记录以生成或修改关系数据库数据结构842中的其他记录。具体而言，控制应用生成LFP数据。虚拟化应用又检测关系数据库数据结构中的这些记录的修改和/或添加，并修改或生成关系数据库数据结构中的其他记录。在此示例中，这些其他记录代表UPCP数据。然后，这些记录通过控制器实例810的控制器间的通信接口850，被发送到正在管理实现特定LDPS的交换元件中的至少一个的另一个控制器实例。

在此示例中，控制器实例815是正在管理交换元件855的控制器实例。交换元件实现特定LDPS的至少一部分。控制器实例815通过控制器间的通信接口865，从控制器实例810接收代表UPCP数据的记录。在一些实施例中，控制器实例815将具有控制应用和虚拟化应用以执行UPCP数据到CPCP数据的转换。然而，在此示例中，控制器实例815只是标识将向其发送UPCP数据的一组管理交换元件。如此，控制器实例815充当收集发送到此控制器负责管理的管理交换元件的数据的聚合点。在此示例中，管理交换元件855是由控制器实例815管理的交换元件中的一个。

D.输入转换层

图9在概念上示出了输入转换应用900的软件体系结构。一些实施例的输入转换应用充当上文参考图5所描述的输入转换层505。具体而言，输入转换应用从允许用户键入输入值的用户界面应用接收输入。输入转换应用将输入转换为请求，并将请求调度到一个或多个控制器实例，以处理请求。在一些实施例中，输入转换应用与控制应用在同一个控制器实例中运行，而在其他实施例中，输入转换应用作为单独的控制器实例来运行。如此图所示，输入转换应用包括输入解析器905、过滤器910、请求生成器915、请求储存库920、调度器925、响应管理器930、以及控制器间的通信接口940。

在一些实施例中，输入转换应用900支持一组用于指定LDP集合和信息查询的API调用。在这些实施例中，实现了允许用户键入输入值的用户界面应用，以将API调用形式的输入发送到输入转换应用900。因此，这些API调用指定LDPS(例如，由用户所指定的逻辑交换元件配置)和/或用户的信息查询(例如，用户的逻辑交换元件的逻辑端口的网络流量统计信息)。此外，在一些实施例中，输入转换应用900还从逻辑控制器、物理控制器、和/或另一个控制器实例的另一个输入转换应用获取输入。

一些实施例的输入解析器905从用户界面应用接收API调用形式的输入。在一些实施例中，输入解析器从API调用中提取用户输入值，并将输入值传递到过滤器910。过滤器910过滤掉不符合某些要求的输入值。例如，过滤器910过滤掉指定逻辑端口的无效网络地址的输入值。对于包含不符合的输入值的那些API调用，响应管理器930将指示输入不符合的响应发送给用户。

请求生成器915生成要被发送到一个或多个控制器实例的请求，控制器实例将处理请求以产生对请求的响应。这些请求可以包含供接收控制器实例处理的LDPS数据和/或信息查询。例如，请求可以要求用户正在管理的逻辑交换元件的逻辑端口的统计信息。对此请求的响应将包括由负责管理与逻辑交换元件相关联的LDPS的控制器实例准备的所请求的统计信息。

不同的实施例的请求生成器915根据不同的格式生成请求，这取决于接收并处理请求的控制器实例的实现。例如，一些实施例的请求生成器915所生成的请求采用适用于存储在接收请求的控制器实例的关系数据库数据结构中的记录的形式(例如，数据元组)。在这些实施例中的一些实施例中，接收方控制器实例使用nLog表映射引擎来处理代表请求的记录。在其他实施例中，请求采用可以与接收请求的控制器实例的NIB数据结构进行交互的面向对象的数据对象的形式。在这些实施例中，接收方控制器实例直接在NIB数据结构上处理数据对象，而不经过nLog表映射引擎。

一些实施例的请求生成器915将所生成的请求储存在请求储存库920中，以便调度器925可以将请求发送到合适的控制器实例。调度器925标识每一个请求应该被发送到的控制器实例。在一些情况下，调度器检查与请求相关联的LDPS并标识作为该LDPS的主控的控制器实例。在一些情况下，当请求具体地涉及交换元件时(例如，当请求是关于被映射到交换元件的端口的逻辑端口的统计信息时)，调度器标识特定交换元件的主控(即，物理控制器)作为发送请求的控制器实例。调度器将请求发送到所标识的控制器实例。当请求包括信息查询时，接收控制器实例返回响应。

控制器之间的通信接口940与上文参考图6所描述的控制器间的通信接口645的类似之处在于，控制器间的通信接口940与另一个控制器实例建立通过其可以发送请求的通信信道(例如，RPC信道)。一些实施例的通信信道是双向的，而在其他实施例中，通信信道是单向的。当信道是单向的时，控制器间的通信接口与另一个控制器实例建立多个信道，以便输入转换应用可以通过不同的信道发送请求和接收响应。

当接收方控制器实例接收到指定信息查询的请求时，控制器实例处理请求，并产生包含被查询的信息的响应。响应管理器930通过由控制器间的通信接口940建立的信道，从处理请求的控制器实例接收响应。在某些情况下，对于发出的请求，可以有一个以上的响应返回。例如，对用户正在管理的逻辑交换元件的所有逻辑端口的统计信息的请求将从每一个控制器返回响应。来自其端口被映射到逻辑端口的多个不同的交换元件的多个物理控制器实例的响应可以返回到输入转换应用900，直接返回到输入转换应用900或通过与逻辑开关相关联的LDPS的主控。在这样的情况下，一些实施例的响应管理器930合并这些响应，并向用户界面应用发送单一合并的响应。

如上文所提及的，在控制器实例中运行的控制应用通过执行转换操作，将代表LCP数据的数据记录转换为代表LFP数据的数据记录。具体而言，在一些实施例中，控制应用利用LDP集合来填充由虚拟化应用创建的LDPS表(例如，逻辑转发表)。

E.nLog引擎

在一些实施例中，控制器实例通过使用nLog表映射引擎(该引擎使用datalog(数据日志)表映射技术的变型)来执行其映射操作。Datalog(数据日志)用于数据库管理领域，以将一组表映射到另一组表。Datalog(数据日志)不是用于在网络控制系统的虚拟化应用中执行表映射操作的合适的工具，因为其当前实现往往很慢。

相应地，一些实施例的nLog引擎被自定义设计以快速地操作，从而它可以执行LDPS数据元组到管理交换元件的数据元组的实时映射。此自定义设计基于若干自定义设计选择。例如，一些实施例根据由应用开发人员(例如，由控制应用的开发人员)表达的一组高级别声明性规则，编译nLog表映射引擎。在这些实施例中的一些实施例中，为nLog引擎做出的一个自定义设计选择是使应用开发人员只使用“AND(与)”算符来表达声明性规则。通过防止开发人员使用其他算符(诸如OR(或)、XOR(异或)等等)，这些实施例确保nLog引擎的作为结果的规则按照在运行时更快地执行的AND(与)操作来表达。

另一自定义设计选择涉及由nLog引擎执行的连接操作。连接操作是用于在不同表的记录之间创建关联的常见的数据库操作。在一些实施例中，nLog引擎将其连接操作限制到内连接操作(也被称为内部连接操作)，因为执行外部连接操作(也被称为外部连接操作)会费时，所以对于引擎的实时操作是不切实际的。

再一个自定义设计选择是将nLog引擎实现为由多个不同的控制器实例执行的分布式表映射引擎。一些实施例通过分割对LDP集合的管理来以分布式方式实现nLog引擎。分割对LDP集合的管理涉及为每一个特定LDPS只指定一个控制器实例，作为负责指定与该特定LDPS相关联的记录的实例。例如，当控制系统使用三个交换元件来指定具有两个不同的控制器实例的五个不同的用户的五个LDP集合时，一个控制器实例可以是涉及LDP集合中的两个组的记录的主控，而另一个控制器实例可以是其他三个LDP集合的记录的主控。

在一些实施例中，分割对LDP集合的管理还将每一个LDPS的表映射操作分配到负责LDPS的控制器实例的nLog引擎。nLog表映射操作跨若干nLog实例的分布降低了每一个nLog实例上的负载，并由此提高每一个nLog实例可以完成其映射操作的速度。此外，此分布还降低执行控制器实例的每一个机器上的存储器大小要求。一些实施例通过将由每一个nLog实例执行的第一连接操作基于LDPS参数，跨不同的实例分割nLog表映射操作。此指定确保，当实例启动一组涉及不由nLog实例管理的LDPS的连接操作时，每一个nLog实例的连接操作失败并立即结束。在上文包括的美国专利申请13/177,533中描述了使用nLog引擎的若干示例。

F.控制层

图10示出了本发明的一些实施例的控制应用1000。在一些实施例中，此应用1000用作图6的控制模块625。此应用1000使用nLog表映射引擎来将包含代表LCP数据的输入数据元组的输入表映射到代表LFP数据的数据元组。此应用驻留在从控制应用1000接收指定LDP集合的数据元组的虚拟化应用1005上面。虚拟化应用1005将数据元组映射到UPCP数据。

更具体而言，控制应用1000允许不同的用户定义不同的LDP集合，LDP集合指定用户管理的逻辑交换元件的期望配置。控制应用1000通过其映射操作将每一个用户的每一个LDPS的数据转换为指定与LDPS相关联的逻辑交换元件的LFP数据的一组数据元组。在一些实施例中，控制应用与虚拟化应用1005在同一个主机上执行。在其他实施例中，控制应用和虚拟化应用不必在同一台机器上运行。

如图10所示，控制应用1000包括一组规则引擎输入表1010、一组函数和常量表1015、导入器1020、规则引擎1025、一组规则引擎输出表1045、转换器1050、导出器1055、PTD1060、以及编译器1035。编译器1035是应用的与应用的其他组件在不同的时间实例上操作的一个组件。当开发人员需要为特定控制应用和/或虚拟化的环境指定规则引擎时，编译器操作，而当应用与虚拟化应用连接以部署由一个或多个用户所指定的LDP集合时，应用的其余模块在运行时操作。

在一些实施例中，编译器1035获取以声明性语言指定的声明性指令1040的相对较小的集合(例如，几百行)，并将它们转换为指定执行应用的表映射的规则引擎1025的操作的代码(即，目标代码)的大的集合(例如，数千行)。如此，编译器大大地简化控制应用开发人员的定义和更新控制应用的过程。这是因为，编译器允许开发人员使用高级程序设计语言，该高级程序设计语言允许控制应用的复杂映射操作的紧凑定义，并随后响应于任意数量的变化(例如，由控制应用支持的逻辑联网功能的变化，对控制应用的期望行为的变化等等)，更新此映射操作。此外，当开发人员正在定义映射操作时，编译器还使开发人员不必考虑事件到达控制应用的顺序。

在一些实施例中，规则引擎(RE)输入表1010包括具有逻辑数据和/或由用户和/或控制应用所指定的交换配置(例如，访问控制列表配置、专用虚拟网络配置、端口安全配置等等)的表。在一些实施例中，输入表1010还包括包含来自由网络控制系统管理的交换元件的物理数据的表。在一些实施例中，这样的物理数据包括关于管理交换元件的数据、以及关于由网络控制系统部署不同用户的不同LDP集合所使用的网络配置的其他数据。

RE输入表1010部分地利用由用户所提供的LCP数据来填充。RE输入表1010还包含LFP数据和UPCP数据。除RE输入表1010之外，控制应用1000还包括其他杂项表1015，其中，规则引擎1025使用其他杂项表1015来收集用于其表映射操作的输入。这些表1015包括常量表，常量表存储规则引擎1025执行其表映射操作所需的常量的定义的值。例如，常量表1015可以包括被定义为值0的常量“零”，被定义为值4000的常量“dispatch_port_no”，以及被定义为值0xFF:FF:FF:FF:FF:FF的常量“broadcast_MAC_addr”。

当规则引擎1025引用常量时，实际检索并使用为常量定义的对应的值。另外，还可以修改和/或更新为常量表1015中的常量定义的值。如此，常量表1015提供修改为规则引擎1025引用的常量定义的值的能力，无需重写或重新编译指定规则引擎1025的操作的代码。表1015还包括存储函数的函数表，规则引擎1025需要使用这些函数来计算填充输出表1045所需的值。

规则引擎1025执行指定用于将LCP数据转换为LFP数据的一种方式的表映射操作。每当修改规则引擎(RE)输入表中的一个时，规则引擎执行可以导致一个或多个RE输出表中的一个或多个数据元组的修改的一组表映射操作。

如图10所示，规则引擎1025包括事件处理器1022、若干查询计划1027、以及表处理器1030。每一个查询计划都是指定在发生对RE输入表中的一个的修改时要执行的一组连接操作的一组规则。这样的修改在下面被称为输入表事件。在此示例中，每一个查询计划都是由编译器1035从声明组1040中的一个声明性规则所生成的。在一些实施例中，从一个声明性规则生成一个以上的查询计划。例如，为由一个声明性规则连接的每一个表创建查询计划。即，当一个声明性规则指定要连接四个表时，将从这一个声明创建四个不同的查询计划。在一些实施例中，查询计划是使用nLog声明性语言来定义的。

规则引擎1025的事件处理器1022检测每一个输入表事件的发生。不同的实施例的事件处理器以不同的方式检测输入表事件的发生。在一些实施例中，事件处理器向RE输入表注册回调，用于通知对RE输入表的记录的更改。在这样的实施例中，当事件处理器1022从RE输入表接收到其记录中的一个记录改变的通知时，它就检测到输入表事件。

响应于检测到的输入表事件，事件处理器1022(1)为检测到的表事件，选择合适的查询计划，以及(2)指示表处理器1030执行查询计划。为执行查询计划，在一些实施例中，表处理器1030执行由查询计划所指定的连接操作，以从一个或多个输入和杂项表1010和1015产生代表一组或多组数据值的一个或多个记录。然后，一些实施例的表处理器1030(1)执行选择操作，以从由连接操作所产生的记录选择数据值的子集，以及(2)将所选数据值的子集写入到一个或多个RE输出表1045中。

在一些实施例中，RE输出表1045存储逻辑和物理网络元件数据属性两者。表1045被称为RE输出表，因为它们存储规则引擎1025的表映射操作的输出。在一些实施例中，RE输出表可被分组为多个不同的类别。例如，在一些实施例中，这些表可以是RE输入表和/或控制应用(CA)输出表。当表中的变化导致规则引擎检测到要求执行查询计划的输入事件时，表是RE输入表。RE输出表1045也可以是生成导致规则引擎执行另一查询计划的事件的RE输入表1010。这样的事件被称为内部输入事件，并且它与外部输入事件完全不同，外部输入事件是由控制应用1000或导入器1020做出的RE输入表修改所引起的事件。

当表中的变化导致导出器1055将更改导出到虚拟化应用1005时，表是CA输出表，如下面所进一步描述的。在一些实施例中，RE输出表1045中的表可以是RE输入表、CA输出表，或RE输入表和CA输出表两者。

导出器1055检测对RE输出表1045的CA输出表的更改。不同的实施例的导出器以不同的方式检测CA输出表事件的发生。在一些实施例中，导出器向CA输出表注册回调，用于通知对CA输出表的记录的更改。在这样的实施例中，当导出器1055从CA输出表接收到其记录中的一个记录改变的通知时，它就检测到输出表事件。

响应于检测到的输出表事件，导出器1055获取修改过的CA输出表中的一些或全部修改过的数据元组，并将此修改过的数据元组传播到虚拟化应用1005的输入表(未示出)。在一些实施例中，代替导出器1055将数据元组推送到虚拟化应用，虚拟化应用1005从CA输出表1045将数据元组拉到虚拟化应用的输入表。在一些实施例中，控制应用1000的CA输出表1045和虚拟化应用1005的输入表可以是相同的。在另一些其他实施例中控制和虚拟化应用使用一组表，以便CA输出表基本上是虚拟化应用(VA)输入表。

在一些实施例中，控制应用不会在输出表1045中保留控制应用不负责管理的LDP集合的数据。然而，这样的数据将由转换器1050转换为可以存储在PTD中并被存储在PTD中的格式。控制应用1000的PTD将此数据传播到其他控制器实例的一个或多个其他控制应用实例，以便负责管理与该数据相关联的LDP集合的一些其他控制器实例可以处理该数据。

在一些实施例中，控制应用还将存储在输出表1045中的数据(即，被控制应用保留在输出表中的数据)带到PTD，以便确保数据的灵活性。这样的数据还由转换器1050转换，存储在PTD中，并被传播到其他控制器实例的其他控制应用实例。因此，在这些实施例中，控制器实例的PTD具有用于由网络控制系统管理的所有LDP集合的所有配置数据。即，在一些实施例中，每一个PTD都包含逻辑网络的配置的全局视图。

导入器1020与输入数据的多个不同的源连接，并使用输入数据来修改或创建输入表1010。一些实施例的导入器1020通过控制器间的通信接口(未示出)从输入转换应用1070接收输入数据。导入器1020还与PTD 1060连接，以便通过PTD从其他控制器实例接收到的数据可以被用作修改或创建输入表1010的输入数据。此外，导入器1020还检测RE输入表和RE输出表1045的RE输入表与CA输出表的变化。

G.虚拟化层

如上文所提及的，一些实施例的虚拟化应用指定网络控制系统的不同用户的不同LDP集合可以通过由网络控制系统管理的交换元件来实现的方式。在一些实施例中，虚拟化应用通过执行转换操作来指定管理交换元件基础结构内的LDP集合的实现。这些转换操作将LDP集合数据记录转换为控制数据记录(例如，UPCP数据)，该控制数据记录最初存储在管理交换元件内，然后被交换元件用来产生用于定义交换元件的转发行为的转发平面数据(例如，流量条目)。转换操作还产生指定应该在管理交换元件内以及在管理交换元件之间定义的网络构造(例如，隧道、队列、队列集合等等)的其他数据(例如，在表中)。网络构造还包括管理的软件交换元件，这些管理的软件交换元件是动态地部署的或预先配置的管理的软件交换元件，它们是动态地添加到管理交换元件集合中。

图11示出了本发明的一些实施例的虚拟化应用1100。在一些实施例中，此应用1100用作图6的虚拟化模块630。虚拟化应用1100使用nLog表映射引擎来映射包含代表UPCP数据的LDPS数据元组的输入表。此应用驻留在生成LDPS数据元组的控制应用1105下面。控制应用1105类似于上文参考图10所描述的控制应用1000。虚拟化应用1100类似于虚拟化应用1005。

如图11所示，虚拟化应用1100包括一组规则引擎输入表1110、一组函数和常量表1115、导入器1120、规则引擎1125、一组规则引擎输出表1145、转换器1150、导出器1155、PTD1160、以及编译器1135。编译器1135类似于上文参考图10所描述的编译器1035。

为了使虚拟化应用1100将LDPS数据元组映射到UPCP数据元组，在一些实施例中，开发人员以声明性语言指定声明性指令1140，该声明性指令1140包括用于针对一些管理交换元件将LDPS数据元组映射到UPCP数据元组的指令。在一些这样的实施例中，这些交换元件包括将UPCP数据转换为CPCP数据的UPCP。

对于其他管理交换元件，虚拟化应用1100将LDPS数据元组映射到特定于没有UPCP的每一个管理交换元件的CPCP数据元组。在一些实施例中，当虚拟化应用1100从另一控制器实例的虚拟化应用接收UPCP数据时，对于不具有将通用物理控制平面数据元组转换为物理数据路径组数据元组的UPCP的一些管理交换元件，虚拟化应用1100进一步将输出表1140中的UPCP数据元组映射到CPCP数据元组。

在一些实施例中，当具有将UPCP元组转换为特定于管理交换元件的CPCP数据的机箱控制器时，虚拟化应用1100对于特定管理交换元件，不将输入UPCP数据转换为CPCP数据。在这些实施例中，具有虚拟化应用1100的控制器实例标识其控制器实例是主控的一组管理交换元件，并将UPCP数据分发到管理交换元件组。

RE输入表1110类似于RE输入表1010。除RE输入表1110之外，虚拟化应用1100还包括其他杂项表1115，其中，规则引擎1125使用其他杂项表1115来收集用于其表映射操作的输入。这些表1115类似于表1015。如图11所示，规则引擎1125包括事件处理器1122、若干查询计划1127、以及表处理器1130，它们与事件处理器1022、查询计划1027、以及表处理器1030功能类似。

在一些实施例中，RE输出表1145存储逻辑和物理网络元件数据属性两者。表1145被称为RE输出表，因为它们存储规则引擎1125的表映射操作的输出。在一些实施例中，RE输出表可被分组为若干不同的类别。例如，在一些实施例中，这些表可以是RE输入表和/或虚拟化应用(VA)输出表。当表中的变化导致规则引擎检测到要求执行查询计划的输入事件时，表是RE输入表。RE输出表1145也可以是在它被规则引擎修改之后生成导致规则引擎执行另一查询计划的事件的RE输入表1110。这样的事件被称为内部输入事件，并且它与外部输入事件完全不同，外部输入事件是由控制应用1105经由导入器1120做出的RE输入表修改所引起的事件。

当表中的变化导致导出器1155将更改输出到管理交换元件或其他控制器实例时，表是VA输出表。如图12所示，在一些实施例中，RE输出表1145中的表可以是RE输入表1110、VA输出表1205，或RE输入表1110和VA输出表两者。

导出器1155检测对RE输出表1145的VA输出表1205的更改。不同的实施例的导出器以不同的方式检测VA输出表事件的发生。在一些实施例中，导出器向VA输出表注册回调，用于通知对VA输出表的记录的更改。在这样的实施例中，当导出器1155从VA输出表接收到其记录中的一个记录改变的通知时，它就检测到输出表事件。

响应于检测到的输出表事件，导出器1155获取修改过的VA输出表中的每一个修改过的数据元组，并将此修改过的数据元组传播到其他控制器实例中的一个或多个(例如，机箱控制器)或一个或多个管理交换元件。在这样做时，导出器完成LDPS(例如，一个或多个逻辑交换配置)向由记录所指定的一个或多个管理交换元件的部署。

由于在一些实施例中，VA输出表存储逻辑和物理网络元件数据属性两者，因此在一些实施例中，PTD 1160存储与输出表1145中的逻辑和物理网络元件数据属性相同的逻辑和物理网络元件数据属性、或从其导出的逻辑和物理网络元件属性两者。然而，在其他实施例中，PTD 1160只存储与输出表1145中的物理网络元件数据属性相同的物理网络元件数据属性、或从其导出的物理网络元件属性。

在一些实施例中，虚拟化应用不会在输出表1145中保留虚拟化应用不负责管理的LDP集合的数据。然而，这样的数据将由转换器1150转换为可以存储在PTD中然后被存储在PTD中的格式。虚拟化应用1100的PTD将此数据传播到其他控制器实例的一个或多个其他虚拟化应用实例，以便负责管理与该数据相关联的LDP集合的一些其他虚拟化应用实例可以处理该数据。

在一些实施例中，虚拟化应用还将存储在输出表1145中的数据(即，被虚拟化应用保留在输出表中的数据)带到PTD，以便确保数据的灵活性。这样的数据还由转换器1150转换，存储在PTD中，并被传播到其他控制器实例的其他虚拟化应用实例。因此，在这些实施例中，控制器实例的PTD具有用于由网络控制系统管理的所有LDP集合的所有配置数据。即，在一些实施例中，每一个PTD都包含逻辑网络的配置的全局视图。

导入器1120与输入数据的若干个不同的源连接，并使用输入数据来修改或创建输入表1110。一些实施例的导入器1120通过控制器间的通信接口(未示出)从输入转换应用1170接收输入数据。导入器1120还与PTD 1160连接，以便通过PTD从其他控制器实例接收到的数据可以被用作修改或创建输入表1110的输入数据。此外，导入器1120还检测RE输入表和RE输出表1145的RE输入表与VA输出表的变化。

H.网络控制器

图13示出了本发明的一些实施例的控制和虚拟化应用的表映射操作的简化视图。如在此图的上半部所示的，控制应用1305将LCP数据映射到LFP数据，然后，一些实施例的虚拟化应用1310将LFP数据映射到UPCP数据或CPCP数据。

此图的下半部分示出了控制应用和虚拟化应用的表映射操作。如此半部所示，控制应用的输入表1315存储LCP数据、LFP(LFP)数据和UPCP数据，因为在一些实施例中，所有这些数据与常量和函数表(未示出)中的数据的集合被控制应用的nLog引擎1320使用，以从输入LCP数据生成LFP数据。

此图示出了，导入器1350从用户接收LCP数据(例如，通过输入转换应用)，并利用LCP数据更新控制应用的输入表1315。此图进一步示出了，在一些实施例中，导入器1350检测或接收PTD 1340中的变化(例如，源自其他控制器实例的LCP数据更改)，并响应于这样的变化，导入器1350可以更新输入表1315。

此图的下半部分还示出了虚拟化应用1310的表映射操作。如图所示，虚拟化应用的输入表1355存储LFP数据，因为在一些实施例中，LFP数据与常量和函数表(未示出)中的数据一起被虚拟化应用的nLog引擎1320使用，以生成UPCP数据和/或CPCP数据。在一些实施例中，在将所生成的UPCP数据推送到将UPCP数据转换为特定于管理交换元件的CPCP数据的管理交换元件或一个或多个管理交换元件之前，导出器1370将所生成的UPCP数据发送到一个或多个其他控制器实例(例如，机箱控制器)，以生成CPCP数据。在其他实施例中，导出器1370将所生成的CPCP数据发送到一个或多个管理交换元件，以定义这些管理交换元件的转发行为。

在一些实施例中，当存在将UPCP数据转换为特定于管理交换元件的CPCP数据的机箱控制器时，虚拟化应用1310对于特定管理交换元件，不将输入UPCP数据转换为CPCP数据。在这些实施例中，具有虚拟化应用1310的控制器实例标识其控制器实例是主控的一组管理交换元件，并将UPCP数据分发到管理交换元件组。

此图示出了，导入器1375从控制应用1305接收LFP数据，并利用LFP数据更新虚拟化应用的输入表1355。此图进一步示出了，在一些实施例中，导入器1375检测或接收PTD1340中的变化(例如，源自其他控制器实例的LCP数据更改)，并响应于这样的变化，导入器1375可以更新输入表1355。此图还示出了，导入器1375可以从另一控制器实例接收UPCP数据。

如上文所提及的，导入器推送到控制应用或虚拟化应用的输入表的一些逻辑或物理数据涉及由其他控制器实例所生成的并传递到PTD的数据。例如，在一些实施例中，涉及多个LDP集合的关于逻辑构造(例如，逻辑端口、逻辑队列等等)的逻辑数据可能会变化，并且转换器(例如，控制器实例的转换器1380)可以将此变化写入到输入表中。当用户为不负责LDPS的第一控制器实例上的LDPS提供LCP数据时，发生由多控制器实例环境中的另一控制器实例产生的这样的逻辑数据的另一示例。此变化被第一控制器实例的转换器添加到第一控制器实例的PTD。然后，通过由PTD执行的复制过程，将此变化跨其他控制器实例的PTD进行传播。作为LDPS的主控或负责LDPS的逻辑控制器的第二控制器实例的导入器最终获取此变化，然后，将变化写入到应用的输入表中的一个(例如，控制应用的输入表)。相应地，在一些情况下导入器将其写入到输入表的逻辑数据可以源自另一控制器实例的PTD。

如上文所提及的，在一些实施例中，控制应用1305和虚拟化应用1310是在同一个机器或不同的机器上操作的两个单独的应用。然而，其他实施例将这两个应用实现为一个集成的应用的两个模块，其中，控制应用模块1305生成LFP中的逻辑数据，而虚拟化应用生成UPCP或CPCP中的物理数据。

还有其他实施例将这两个应用的控制和虚拟化操作集成在一个集成的应用内，而不会将这些操作分离为两个分离的模块。图14示出了这样的集成的应用1400的示例。此应用1400使用nLog表映射引擎1410将来自表1415的输入集的数据映射到表1420的输出集，该表1420的输出集类似于上文所描述的实施例图10、11、以及13，可以包括表的输入集中的一个或多个表。此集成的应用中的表的输入集可以包括需要被映射到LFP数据的LCP数据，或者它可以包括需要被映射到CPCP或UPCP数据的LFP数据。表的输入集还可以包括需要被映射到CPCP数据的UPCP数据。UPCP数据被分发到一组管理交换元件的一组机箱控制器，而不会被映射到CPCP数据。映射取决于运行集成的应用1400的控制器实例是逻辑控制器还是物理控制器，以及物理控制器的管理交换元件是否是具有用于针对管理交换元件将UPCP数据映射到CPCP数据的机箱控制器的主控。

在此集成的控制和虚拟化应用1400中，导入器1430从用户或其他控制器实例获得输入数据。导入器1430还检测或接收被复制到PTD的PTD 1440的变化。导出器1425将输出表记录导出到其他控制器实例(例如，机箱控制器)。

当将输出表记录发送到另一控制器实例时，导出器使用控制器间的通信接口(未示出)，以便包含在记录中的数据通过通信信道(例如，RPC信道)被发送到其他控制器实例。当将输出表记录发送到管理交换元件时，导出器使用管理交换元件通信接口(未示出)，以便包含在记录中的数据通过两个信道被发送到管理交换元件。一个信道是使用用于控制管理交换元件的转发平面的交换控制协议(例如，OpenFlow(开放流))建立的，而另一个信道是使用发送配置数据的配置协议建立的。

当将输出表记录发送到机箱控制器时，在一些实施例中，导出器1425使用单一通信信道发送包含在记录中的数据。在这些实施例中，机箱控制器通过此单信道来接受数据，但是通过两个信道来与管理交换元件进行通信。下面参考图18来进一步更详细地描述机箱控制器。

图15示出了这样的集成的应用1500的另一示例。集成的应用1500使用网络信息库(NIB)数据结构1510来存储nLog表映射引擎1410的一些输入和输出数据。如上文所提及的，NIB数据结构以面向对象的数据对象的形式来存储数据。在集成的应用1500中，输出表1420是主存储器结构。PTD 1440和NIB 1510是辅助存储器结构。

集成的应用1500使用nLog表映射引擎1410将来自表1415的输入集的数据映射到表1420的输出集。在一些实施例中，表1420的输出集中的一些数据被导出器1425导出到一个或多个其他控制器实例或一个或多个管理交换元件。这样的导出的数据包括可定义管理交换元件的流行为的UPCP或CPCP数据。这些数据可以由PTD 1440中的转换器1435备份在PTD中，以便确保数据灵活性。

表1420的输出集中的一些数据被NIB发布器1505发布到NIB1510。这些数据包括用户使用集成的应用1500来管理的逻辑交换元件的配置信息。存储在NIB 1510中的数据被协调管理器1520复制到其他控制器实例的其他NIB。

NIB监视器1515从NIB 1510接收变化的通知，并针对一些通知(例如，与集成的应用是其主控的LDP集合有关的那些通知)，经由导入器1430将变化推送到输入表1415。

查询管理器1525使用控制器间的通信接口(未示出)与输入转换应用(未示出)连接，以接收关于配置数据的查询(例如，信息查询)。如此图所示，一些实施例的管理器1525还与NIB 1510连接，以便查询NIB以提供关于用户正在管理的逻辑网络元件的状态信息(例如，逻辑端口统计信息)。然而，在其他实施例中，查询管理器1525查询输出表1420以获得状态信息。

在一些实施例中，应用1500使用除PTD和NIB以外的辅助存储器结构(未示出)。这些结构包括持久性非事务数据库(PNTD)和哈希表。在一些实施例中，这两种类型的辅助存储器结构存储不同类型的数据，以不同的方式来存储数据，和/或提供处理不同类型的查询的不同的查询界面。

PNTD是存储在磁盘上或其他非易失性存储器上的持久性数据库。一些实施例使用此数据库来存储关于一个或多个交换元件属性或操作的数据(例如，统计信息、计算等等)。例如，在一些实施例中，此数据库用于存储通过特定交换元件的特定端口路由的数据包的数量。存储在PNTD中的数据的类型的其他示例包括错误消息、日志文件、警告消息，以及帐单数据。

在一些实施例中，PNTD具有可以处理数据库查询的数据库查询管理器(未示出)，但是，由于它不是事务数据库，因此，此查询管理器不能处理复杂的条件事务性查询。在一些实施例中，对PNTD的访问比对PTD的访问更快，但是比对哈希表的访问慢。

与PNTD不同，哈希表不是存储在磁盘上或其他非易失性存储器上的数据库。相反，它是存储在易失性系统存储器(例如，RAM)中的存储结构。它使用那些使用哈希索引来快速地标识存储在表中的记录的哈希技术。与哈希表在系统存储器中的布局相结合的此结构可使此表被非常快地访问。为促进此快速访问，在一些实施例中使用简化的查询界面。例如，在一些实施例中，哈希表只有两个查询：为将值写入到表中的Put(放入)查询和用于从表中检索值的Get(获取)查询。一些实施例使用哈希表来存储快速变化的数据。这样的快速变化的数据的示例包括网络实体状态、统计信息、状态、正常运行时间、链接布局、以及数据包处理信息。此外，在一些实施例中，集成的应用还使用哈希表来作为被重复地查询的信息的缓存，例如将被写入到多个节点的流条目。一些实施例在NIB中使用哈希结构，以便快速地访问NIB中的记录。相应地，在这些实施例中的一些中，哈希表是NIB数据结构的一部分。

PTD和PNTD通过在硬盘上保留网络数据来改善控制器的灵活性。如果控制器系统发生故障，则网络配置数据将被保留在PTD中的磁盘上，并且日志文件信息将被保留在PNTD中的磁盘上。

I.网络控制系统层次结构

图16在概念上示出了网络控制系统1600的示例体系结构。具体而言，此图示出了由网络控制系统的不同元件根据输入生成CPCP数据。如图所示，一些实施例的网络控制系统1600包括输入转换控制器1605、逻辑控制器1610、物理控制器1615和1620、以及三个管理交换元件1625-1635。此图还示出了连接到管理交换元件(在图中被写为“M.S.E.”)1625-1635的五个机器1640-1660以在它们之间交换数据。此图所示出的体系结构的细节，诸如层次结构中的每一层中的控制器的数量、管理交换元件以及机器的数量，以及控制器、管理交换元件、机器之间的关系，只是为了说明。那些精通本技术的普通人员将认识到，对于网络控制系统1600，控制器、交换元件、以及机器的许多其他不同的组合也是可以的。

在一些实施例中，网络控制系统中的每一个控制器都具有上文参考图6所描述的不同的模块和接口的完全的堆栈。然而，每一控制器不必使用所有的模块和接口以便执行针对控制器给定的功能。可替选地，在一些实施例中，系统中的控制器只有那些执行针对控制器给定的功能所需的模块和接口。例如，作为LDPS的主控的逻辑控制器1610不包括输入模块(例如，输入转换应用)，但是包括控制模块和虚拟化模块(例如，控制应用或虚拟化应用，或集成的应用)以根据输入LCP数据生成UPCP数据。

此外，不同的控制器的不同的组合可以在同一机器上运行。例如，输入转换控制器1605和逻辑控制器1610可以在同一个计算设备中运行。此外，一个控制器还可以针对不同的LDP集合以不同的方式起作用。例如，单一控制器可以是第一LDPS的主控并且是实现第二LDPS的管理交换元件的主控。

输入转换控制器1605包括输入转换应用(未示出)，该输入转换应用利用从指定特定LDPS的用户接收到的输入生成LCP数据。输入转换控制器1605根据系统1605的配置数据标识LDPS的主控。在此示例中，LDPS的主控是逻辑控制器1610。在一些实施例中，一个以上的控制器可以是同一个LDPS的主控。此外，一个逻辑控制器还可以是一个以上的LDP集合的主控。

逻辑控制器1610负责特定LDPS。如此，逻辑控制器1610根据从输入转换控制器接收到的LCP数据来生成UPCP数据。具体而言，逻辑控制器1610的控制模块(未示出)根据接收到的LCP数据来生成LFP数据，而逻辑控制器1610的虚拟化模块(未示出)根据LFP数据来生成UPCP数据。

逻辑控制器1610标识作为实现LDPS的管理交换元件的主控的物理控制器。在此示例中，逻辑控制器1610标识物理控制器1615和1620，因为管理交换元件1625-1635在此示例中被配置成实现LDPS。逻辑控制器1610将所生成的UPCP数据发送到物理控制器1615和1620。

物理控制器1615和1620中的每一个可以是一个或多个管理交换元件的主控。在此示例中，物理控制器1615是两个管理交换元件1625和1630的主控，而物理控制器1620是管理交换元件1635的主控。作为一组管理交换元件的主控，一些实施例的物理控制器从接收到的UPCP数据生成特定于每一个管理交换元件的CPCP数据。因此，在此示例中，物理控制器1615生成针对管理交换元件1625和1630中的每一个而自定义的PCP数据。物理控制器1320生成针对管理交换元件1635而自定义的PCP数据。物理控制器将CPCP数据发送到其控制器是主控的管理交换元件。在一些实施例中，多个物理控制器可以是同一个管理交换元件的主控。

除发送CPCP数据之外，一些实施例的物理控制器还从管理交换元件接收数据。例如，物理控制器接收管理交换元件的配置信息(例如，管理交换元件的VIF的标识符)。物理控制器维护配置信息，并且还将信息向上发送到逻辑控制器，以便逻辑控制器具有用于实现LDP集合(其逻辑控制器是主控)的管理交换元件的配置信息。

管理交换元件1625-1635中的每一个根据由管理交换元件接收到的CPCP数据生成物理转发平面数据。如上文所提及的，物理转发平面数据定义管理交换元件的转发行为。换言之，管理交换元件使用CPCP数据来填充其转发表。管理交换元件1625-1635根据转发表在机器1640-1660之间转发数据。

图17在概念上示出了网络控制系统1700的示例体系结构。类似于图16，此图示出了由网络控制系统的不同元件根据输入生成CPCP数据。与图16中的网络控制系统1600相比，网络控制系统1700包括机箱控制器1725-1735。如图所示，一些实施例的网络控制系统1700包括输入转换控制器1705、逻辑控制器1610、物理控制器1715和1720、机箱控制器1725-1735、以及三个管理交换元件1740-1750。此图还示出了连接到管理交换元件1740-1750的五个机器1755-1775以在它们之间交换数据。此图所示出的体系结构的细节，诸如层次结构中的每一层中的控制器的数量、管理交换元件以及机器的数量，以及控制器、管理交换元件、机器之间的关系，只是为了说明。那些精通本技术的普通人员将认识到，对于网络控制系统1700，控制器、交换元件、以及机器的许多其他不同的组合也是可以的。

输入转换控制器1705与输入转换控制器1605的类似之处在于，输入转换控制器1705包括根据从指定特定LDPS的用户接收到的输入来生成LCP数据的输入转换应用。输入转换控制器1705根据系统1705的配置数据1705标识LDPS的主控。在此示例中，LDPS的主控是逻辑控制器1710。

逻辑控制器1710与逻辑控制器1610的类似之处在于，逻辑控制器1710根据从输入转换控制器1705接收到的LCP数据来生成UPCP数据。逻辑控制器1710标识作为实现LDPS的管理交换元件的主控的物理控制器。在此示例中，逻辑控制器1710标识物理控制器1715和1720，因为管理交换元件1740-1750在此示例中被配置成实现LDPS。逻辑控制器1710将所生成的UPCP数据发送到物理控制器1715和1720。

类似于物理控制器1615和1620，物理控制器1715和1720中的每一个可以是一个或多个管理交换元件的主控。在此示例中，物理控制器1715是两个管理交换元件1740和1745的主控，而物理控制器1730是管理交换元件1750的主控。然而，物理控制器1715和1720针对管理交换元件1740-1750不生成CPCP数据。作为管理交换元件的主控，物理控制器将UPCP数据发送到负责每一个管理交换元件(其物理控制器是主控)的机箱控制器。即，一些实施例的物理控制器标识机箱控制器，该机箱控制器连接其物理控制器是主控的管理交换元件。在一些实施例中，物理控制器通过判断机箱控制器是否预订物理控制器的信道来标识这些机箱控制器。

一些实施例的机箱控制器与管理交换元件具有一对一关系。机箱控制器从作为管理交换元件的主控的物理控制器接收UPCP数据，并生成特定于管理交换元件的CPCP数据。下面将参考图18来进一步描述机箱控制器的示例体系结构。在一些实施例中，机箱控制器与机箱控制器管理的管理交换元件在同一个机器中运行，而在其他实施例中，机箱控制器和管理交换元件在不同的机器中运行。在此示例中，机箱控制器1725和管理交换元件1740在同一个计算设备中运行。

类似于管理交换元件1625-1635，管理交换元件1740-1750中的每一个根据由管理交换元件接收到的CPCP数据来生成物理转发平面数据。管理交换元件1740-1750使用CPCP数据来填充它们的相应的转发表。管理交换元件1740-1750根据流表在机器1755-1775之间转发数据。

如上文所提及的，在某些情况下，管理交换元件可以实现一个以上的LDPS。在这样的情况下，作为这样的管理交换元件的主控的物理控制器接收每一个LDP集合的UPCP数据。如此，网络控制系统1700中的物理控制器可以充当用于针对实现LDP集合的特定管理交换元件将不同的LDP集合的UPCP数据中继到机箱控制器的聚合点。

尽管图17中所示出的机箱控制器是管理交换元件之上的层次，但是，机箱控制器通常与管理交换元件在同一层次上操作，因为一些实施例的机箱控制器在管理交换元件内或与管理交换元件相邻。

在一些实施例中，网络控制系统可以具有网络控制系统1600和1700的混合。即，在此混合网络控制系统中，一些物理控制器针对一些管理交换元件生成CPCP数据，而一些物理控制器针对一些管理交换元件不生成CPCP数据。对于后者的管理交换元件，混合型系统具有生成CPCP数据的机箱控制器。

如上文所提及的，一些实施例的机箱控制器是用于管理单一管理交换元件的控制器。一些实施例的机箱控制器没有上文参考图6所描述的不同的模块和接口的完全的堆栈。机箱控制器具有的模块之一是根据它从一个或多个物理控制器接收到的UPCP数据来生成CPCP数据的机箱控制应用。图18示出了机箱控制应用1800的示例体系结构。此应用1800使用nLog表映射引擎将包含代表UPCP数据的输入数据元组的输入表映射到代表LFP数据的数据元组。此应用1800在此示例中通过与管理交换元件1885交换数据来管理“管理交换元件1885”。在一些实施例中，应用1800(即，机箱控制器)与管理交换元件1885在同一个机器中运行。

如图18所示，机箱控制应用1800包括一组规则引擎输入表1810、一组函数和常数表1815、导入器1820、规则引擎1825、一组规则引擎输出表1845、导出器1855、管理交换元件通信接口1865、以及编译器1835。此图还示出了物理控制器1805和管理交换元件1885。

编译器1835类似于图10中的编译器1035。在一些实施例中，规则引擎(RE)输入表1810包括具有UPCP数据和/或作为管理交换元件1885的主控的物理控制器1805发送到机箱控制应用1800的交换配置(例如，访问控制列表配置、专用虚拟网络配置、端口安全配置等等)的表。输入表1810还包括包含来自管理交换元件1885的物理数据的表。在一些实施例中，这样的物理数据包括关于管理交换元件1885的数据(例如，CPCP数据、物理转发数据)及关于管理交换元件1885的配置的其他数据。

RE输入表1810类似于RE输入表1010。输入表1810部分地利用由物理控制器1805所提供的UPCP数据来填充。一些实施例的物理控制器1805从一个或多个逻辑控制器(未示出)接收UPCP数据。

除输入表1810之外，机箱控制应用1800包括其他杂项表1815，其中，规则引擎1825使用其他杂项表1815来收集用于其表映射操作的输入。这些表1815类似于表1015。如图18所示，规则引擎1825包括事件处理器1822、多个查询计划1827、以及表处理器1830，它们与事件处理器1022、查询计划1027，以及表处理器1030功能类似。

在一些实施例中，RE输出表1845存储逻辑和物理网络元件数据属性两者。表1845被称为RE输出表，因为它们存储规则引擎1825的表映射操作的输出。在一些实施例中，RE输出表可被分组为若干不同的类别。例如，在一些实施例中，这些表可以是RE输入表和/或机箱控制器应用(CCA)输出表。当表中的变化导致规则引擎检测到要求执行查询计划的输入事件时，表是RE输入表。RE输出表1845也可以是在它被规则引擎修改之后生成导致规则引擎执行另一查询计划的事件的RE输入表1810。这样的事件被称为内部输入事件，它与外部输入事件完全不同，外部输入事件是由控制应用1805通过导入器1820做出的RE输入表修改所引起的事件。当表中的变化导致导出器1855将更改导出到管理交换元件或其他控制器实例时，表是CCA输出表。

导出器1855检测对RE输出表1845的CCA输出表的更改。不同的实施例的导出器以不同的方式检测CCA输出表事件的发生。在一些实施例中，导出器向CCA输出表注册回调，用于通知对CCA输出表的记录的更改。在这样的实施例中，当导出器1855从CCA输出表接收到其记录中的一个记录改变的通知时，它就检测到输出表事件。

响应于检测到的输出表事件，导出器1855获取修改过的VA输出表中的每一个修改过的数据元组，并将此修改过的数据元组传播到其他控制器实例中的一个或多个(例如，物理控制器)或管理交换元件1885。导出器1855使用控制器间的通信接口(未示出)将修改过的数据元组发送到其他控制器实例。控制器间的通信接口与其他控制器实例建立通信信道(例如，RPC信道)。

一些实施例的导出器1855使用管理交换元件通信接口1865将修改过的数据元组发送到管理交换元件1885。一些实施例的管理交换元件通信接口建立两个通信信道。管理交换元件通信接口使用交换控制协议来建立两个信道中的第一信道。交换控制协议的一个示例是开放流协议。在一些实施例中，开放流协议是用于控制交换元件的转发平面(例如，转发表)的通信协议。例如，开放流协议提供用于向管理交换元件1885中添加流条目、从其中删除流条目、以及修改其中的流条目的命令。

管理交换元件通信接口使用配置协议来建立两个信道中的第二信道以发送配置信息。在一些实施例中，配置信息包括用于配置管理交换元件1885的信息，例如用于配置进入端口、外出端口的信息、端口的QoS配置，等等。

管理交换元件通信接口1865通过两个信道从管理交换元件接收管理交换元件1885中的更新。当存在不是由机箱控制应用1800启动的管理交换元件1885的流条目或配置的变化时，一些实施例的管理交换元件1885向机箱控制应用发送更新。这样的变化的示例包括连接到管理交换元件1885的端口的机器的故障，向管理交换元件1885的VM迁移等等。管理交换元件通信接口1865向导入器1820发送将修改一个或多个输入表1810的更新。当存在由规则引擎1825根据这些更新产生的输出时，导出器1855将把此输出发送到物理控制器1805。

J.生成流条目

图19示出了基于UPCP数据在两个管理交换元件之间的隧道的示例创建。具体而言，此图以四个不同的阶段1901-1904示出了由网络管理系统1900的不同的组件执行的一系列操作，以便在两个管理交换元件1925和1930之间建立隧道。此图还示出了逻辑交换元件1905和VM 1和VM 2。四个阶段1901-1904中的每一个都在底部部分示出了网络控制系统1900和管理交换元件1925和1930，并且在顶部部分示出了逻辑交换元件1905和连接到逻辑交换元件1905的VM。在每一阶段的顶部和底部部分都示出了VM。

如第一阶段1901所示，逻辑交换元件1905在VM 1和VM 2之间转发数据。具体而言，数据通过逻辑交换元件1905的逻辑端口1来往于VM 1，并且数据通过逻辑交换元件1905的逻辑端口2来往于VM 2。在此示例中，逻辑交换元件1905是通过管理交换元件1925来实现的。即，逻辑端口1被映射到管理交换元件1925的端口3，并且逻辑端口2被映射到管理交换元件1925的端口4。

在此示例中，网络控制系统1900包括控制器集群1910和两个机箱控制器1915和1920。控制器集群1910包括输入转换控制器(未示出)、逻辑控制器(未示出)、以及物理控制器(未示出)，它们基于由控制器集群1910接收到的输入共同地生成UPCP数据。机箱控制器接收UPCP数据，并将通用数据自定义为特定于每一机箱控制器正在管理的管理交换元件的PCP数据。机箱控制器1915和1920将CPCP数据分别传递到管理交换元件1925和1930，以便管理交换元件1925和1930可以生成转发平面数据，其中，物理管理交换元件使用转发平面数据在管理交换元件1925和1930之间转发数据。

在第二阶段1902，包括管理交换元件1930的网络的管理员在管理交换元件1930所运行的主机(未示出)中创建VM 3。管理员创建管理交换元件1930的端口5并将VM 3附接到端口。在创建端口3时，一些实施例的管理交换元件1930将有关新创建的端口的信息发送到控制器集群1910。在一些实施例中，信息可以包括端口号、网络地址(例如，IP和MAC地址)、管理交换元件所属的传输区域、附接到端口的机器等等。如上文所提及的，此配置信息穿过正在管理“管理交换元件”的机箱控制器，然后穿过物理控制器和逻辑控制器，一直到管理逻辑交换元件1905的用户。对此用户，新VM变得可用以被添加到用户正在管理的逻辑交换元件1905。

在阶段1903，在此示例中，用户决定使用VM 3，并将VM 3附接到逻辑交换元件1905。结果，创建逻辑交换元件1905的逻辑端口6。因此，来往于VM 3的数据将穿过逻辑端口6。在一些实施例中，控制器集群1910指示实现逻辑交换元件的所有管理交换元件，以在具有逻辑交换元件的一对逻辑端口被映射到的一对端口的每一对管理交换元件之间创建隧道。在此示例中，可以在管理交换元件1925和1930之间建立隧道，以促进逻辑端口1和逻辑端口6之间(即，VM 1和VM 3之间)以及在逻辑端口2和逻辑端口6之间(即，在VM 2和VM 3之间)的数据交换。即，在管理交换元件1925的端口3和管理交换元件1930的端口5之间交换的数据和在管理交换元件1925的端口4和管理交换元件1930的端口5之间交换的数据可以穿过在管理交换元件1925和1930之间建立的隧道。

不需要两个管理交换元件之间的隧道来促进逻辑端口1和逻辑端口2之间(即，在VM 1和VM 2之间)的数据交换，因为逻辑端口1和逻辑端口2被映射到同一个管理交换元件1925上的两个端口。

第三阶段1903进一步示出了，控制器集群1910将指定从管理交换元件1925创建隧道的指令的UPCP数据发送到管理交换元件1930。在此示例中，UPCP数据被发送到机箱控制器1915，该机箱控制器1915将把UPCP数据自定义为特定于管理交换元件1925的PCP数据。

第四阶段1904示出了，机箱控制器1915向隧道发送指定创建隧道并将数据包转发到隧道的指令的PCP数据。管理交换元件1925基于CPCP数据来创建到管理交换元件1930的隧道。更具体而言，管理交换元件1925创建端口7并建立到管理交换元件1930的端口8的隧道(例如，GRE隧道)。下面将描述在两个管理交换元件之间创建隧道的更详细的操作。

图20在概念上示出了一些实施例所执行的从UPCP数据生成CPCP数据的处理2000，该CPCP数据指定在两个管理交换元件之间创建并使用隧道。在一些实施例中，处理2000是由与管理交换元件连接的机箱控制器或直接与管理交换元件连接的物理控制器执行的。

处理2000通过从逻辑控制器或物理控制器接收UPCP数据开始。在一些实施例中，UPCP数据具有不同类型。UPCP数据的类型之一是通用隧道流指令，这些指令指定在管理交换元件中创建隧道以及隧道的使用。在一些实施例中，通用隧道流指令包括有关在网络中的管理交换元件创建的端口的信息。此端口是用户将逻辑交换元件的逻辑端口映射到的管理交换元件的端口。此端口还是被隧道化的数据需要到达的目的地端口。有关端口的信息包括：(1)具有端口的管理交换元件所属的传输区域，(2)在一些实施例中，基于用于构建到具有目的地端口的管理交换元件的隧道的隧道协议(例如，GRE、CAPWAP等等)的隧道类型，以及(3)具有目的地端口(例如，将充当要建立的隧道的一端的VIF的IP地址)的管理交换元件的网络地址(例如，IP地址)。

接下来，处理2000确定(在2010)接收到的UPCP数据是否是通用隧道流指令。在一些实施例中，UPCP数据指定其类型，以便处理2000可以确定接收到的通用平面数据的类型。当处理2000确定(在2010处)接收到的通用数据不是通用隧道流指令时，处理前进到2015以处理UPCP数据以生成CPCP数据，并将所生成的数据发送到处理2000正在管理的管理交换元件。然后，处理2000结束。

当处理2000确定(在2010处)接收到的UPCP数据是通用隧道流指令时，处理2000前进到2020以解析数据，从而获得有关目的地端口的信息。然后，处理2000确定(在2025处)具有目的地端口的管理交换元件是否与具有源端口的管理交换元件处于同一个传输区域中。具有源端口的管理交换元件是执行处理2000的机箱控制器或物理控制器管理的管理交换元件。在一些实施例中，传输区域包括可以相互进行通信而不会使用诸如池节点之类的第二级别的管理交换元件的一组机器。

在一些实施例中，逻辑控制器判断具有目的地端口的管理交换元件是否与具有源端口的管理交换元件处于同一个传输区域中。逻辑控制器在准备要发送到执行处理2000的机箱控制器(通过物理控制器)的通用隧道流指令时考虑此判断。具体而言，通用隧道流指令将包括用于创建不同的隧道的不同的信息。下面将在图21的描述之后描述这些不同的隧道示例。在这些实施例中，处理2000跳过2025并前进到2015。

当处理2000确定(在2025处)具有源端口的管理交换元件和具有目的地端口的管理交换元件不在同一个传输区域中时，处理2000前进到上文所描述的2015。否则，处理前进到2030，以自定义通用隧道流指令，并将自定义的信息发送到具有源端口的管理交换元件。下面将详细地描述自定义通用隧道流指令。然后，处理2000结束。

图21在概念上示出了处理2100，一些实施例执行该处理2100以生成自定义的隧道流指令，并将自定义指令发送到管理交换元件，以便管理交换元件可以创建隧道，并通过该隧道将数据发送到目的地。在一些实施例中，处理2100是由与管理交换元件连接的机箱控制器实例或直接与管理交换元件连接的物理控制器执行的。在一些实施例中，当执行处理2100的控制器接收到通用隧道流指令，解析有关目的地端口的端口信息，并判断具有目的地端口的管理交换元件与控制器管理的管理交换元件处于同一个传输区域时，处理2100开始。

处理2100通过生成(在2105处)用于创建隧道端口的指令而开始。在一些实施例中，处理2100基于端口信息，生成用于在控制器管理的管理交换元件中创建隧道端口的指令。指令包括，例如，要建立的隧道的类型，以及将是隧道的目的地末端的NIC的IP地址。由控制器管理的管理交换元件的隧道端口将是隧道的另一端。

接下来，处理2100将所生成的用于创建隧道端口的指令发送(在2110处)到控制器管理的管理交换元件。如上文所提及的，一些实施例的机箱控制器或直接与管理交换元件连接的物理控制器使用两个信道与管理交换元件进行通信。一个信道是与管理交换元件交换配置信息的配置信道，另一个信道是用于与管理交换元件交换流条目和事件数据的交换元件控制信道(例如，使用开放流协议建立的信道)。在一些实施例中，处理使用配置信道将用于创建隧道端口的所生成的指令发送到控制器管理的管理交换元件。在接收到所生成的指令时，一些实施例的管理交换元件在管理交换元件中创建隧道端口，并使用由隧道类型所指定的隧道协议，在隧道端口和具有目的地端口的管理交换元件的端口之间建立隧道。当创建并建立隧道端口和隧道时，一些实施例的管理交换元件将隧道的标识符的值(例如，四)发送回到控制器实例。

然后，一些实施例的处理2100通过配置信道，接收(在2115处)隧道端口的标识符的值(例如，“tunnel_port＝4”)。然后，处理2100使用此接收到的值来修改通用隧道流指令中所包括的流条目。当被发送到管理交换元件时，此流条目导致管理交换元件执行动作。然而，作为通用数据，此流条目通过通用标识符(例如，tunnel_port)而不是通过实际端口号来标识隧道端口。例如，接收到的通用隧道流指令中的此流条目可以是“如果目的地＝目的地机器的UUID,则发送到tunnel_port”。处理2100利用隧道端口的标识符的值来创建(在2120处)流条目。具体而言，处理2100用标识创建的端口的标识符的实际值来替换隧道端口的标识符。例如，修改的流条目看起来像“如果目的地＝目的地机器的UUID,则发送到4.”

然后，处理2100将此流条目发送(在2125处)到管理交换元件。在一些实施例中，处理通过交换元件控制信道(例如，开放流信道)将此流量条目发送到管理交换元件。管理交换元件将使用此流条目来更新其流条目表。管理交换元件从那以后通过隧道，通过将数据发送到隧道端口，转发发往目的地机器的数据。然后，处理结束。

图22以七个不同的阶段2201-2207示出了将通用隧道流指令转换为自定义指令供管理交换元件2215接收并使用的机箱控制器2210的示例操作。机箱控制器2210类似于上文参考图18所描述的机箱控制器1800。然而，为讨论简明起见，图22中并非示出了机箱控制器2210的所有组件。

如图所示，机箱控制器2210包括输入表2220、规则引擎2225、以及输出表2230，它们类似于输入表1820、规则引擎1825、以及输出表1845。机箱控制器2210管理“管理交换元件2215”。在一些实施例中，在机箱控制器和管理交换元件2215之间建立两个信道2235和2240。信道2235用于交换配置数据(例如，有关创建端口、端口的当前状态，与管理交换元件相关联的队列等等的数据)。在一些实施例中，信道2240是用来交换流条目的开放流信道(开放流控制信道)。

第一阶段2201示出了，机箱控制器2210使用从物理控制器(未示出)接收到的通用隧道流指令，更新输入表2220。如图所示，通用隧道流指令包括用于创建隧道和流条目2250的指令2245。如图所示，指令2245包括要被创建的隧道的类型，以及具有目的地端口的管理交换元件的IP地址。流条目2250指定根据不是特定于管理交换元件2215的通用数据而采取的动作。规则引擎对指令2245和流条目2250执行表映射操作。

第二阶段2202示出了由规则引擎2225执行的表映射操作的结果。指令2260源于指令2245。在一些实施例中，指令2245和2260可以是相同的，而在其他实施例中，它们可以不相同。例如，指令2245和2260中的代表隧道类型的值可以不同。指令2260包括要被创建的隧道的IP地址和类型，还有可以被包括在指令2260中的其他信息。流条目2250不会触发任何表映射操作，如此，仍保留在输入表2220中。

第三阶段2203示出了指令2260通过配置信道2235被推送到管理交换元件2215。管理交换元件2215创建隧道端口并在管理交换元件2215和具有目的地端口的另一管理交换元件之间建立隧道。在一些实施例中，隧道的一端是创建的隧道端口，隧道的另一端是与目的地IP地址相关联的端口。一些实施例的管理交换元件2215使用由隧道类型所指定的协议来建立隧道。

第四阶段2204示出了管理交换元件2215创建了隧道端口(在此示例中，“端口1”)和隧道2270。此阶段还示出了管理交换元件发送回的隧道端口标识符的实际值。在此示例中，管理交换元件2215通过开放流信道2240发送此信息。该信息进入输入表2220中作为输入事件数据。第五阶段2205示出了利用来自管理交换元件2215的信息来更新输入表2220。此更新触发规则引擎2225执行表映射操作。

第六阶段2206示出了在前一阶段2204执行的表映射操作的结果。输出表2230现在具有指定根据特定于管理交换元件2215的信息而采取的动作的流条目2275。具体而言，流条目2275指定，当数据包的目的地是目的地端口时，管理交换元件2215应该通过端口1发出数据包。第七阶段2207示出了，流条目2275被推送到管理交换元件2215，该管理交换元件2215将使用流条目2275来转发数据包。

应当注意，如图22所示的在机箱控制器2210和管理交换元件2215之间交换的指令2245和数据是通用隧道流指令和自定义指令的概念表示，并且可以不是实际表示和格式。

此外，图22的示例是根据机箱控制器2210的操作描述的。此示例还适用于一些实施例的将UPCP数据转换为管理交换元件(其物理控制器是主控)的CPCP数据的物理控制器。

图19-22示出了在两个管理的边缘交换元件之间创建隧道，以促进在使用逻辑交换元件的两个逻辑端口的一对机器(例如，VM)之间进行数据交换。此隧道涵盖隧道的可能的用途中的一种。在本发明的一些实施例中，隧道的许多其他用途在网络控制系统中是可能的。隧道的示例用途包括：(1)管理的边缘交换元件和池节点之间的隧道，(2)两个管理交换元件之间的隧道，一个管理交换元件是边缘交换元件，另一个提供L3网关服务(即，连接到路由器以在网络层(L3)获取路由服务的管理交换元件)，以及(3)两个管理交换元件之间的隧道，其中，逻辑端口和附接到L2网关服务的另一逻辑端口。

现在将描述三个示例中的每一个中的用于创建隧道的事件序列。对于管理交换元件和池节点之间的隧道，首先提供池节点，然后提供管理交换元件。VM连接到管理交换元件的端口。此VM是连接到管理交换元件的第一VM。然后，通过将逻辑端口映射到管理交换元件的端口，将此VM绑定到逻辑交换元件的逻辑端口。一旦执行了逻辑端口到管理交换元件的端口的映射，逻辑控制器将通用隧道流指令(例如，通过物理控制器)发送到连接管理交换元件的机箱控制器(或物理控制器)。

然后，机箱控制器指示管理交换元件创建到池节点的隧道。一旦创建了隧道，随后提供的并连接到管理交换元件的另一VM将共享同一个隧道，以与池节点交换数据，如果此新VM被绑定到同一个逻辑交换元件的逻辑端口。如果新节点被绑定到不同的逻辑交换机的逻辑端口，则逻辑控制器将发送当第一VM连接到管理交换元件时向下传递的同一个通用隧道流指令。然而，通用隧道流指令将不会导致创建到池节点的新隧道，因为，例如，隧道已经被创建并操作。

如果建立的隧道是单向隧道，则从池节点一侧建立另一单向隧道。当第一VM被绑定到的逻辑端口被映射到管理交换元件的端口时，逻辑控制器还向池节点发送通用隧道流指令。基于通用隧道流指令，连接池节点的机箱控制器将指示池节点创建到管理交换元件的隧道。

对于管理的边缘交换元件和提供L3网关服务的管理交换元件之间的隧道，假设提供了具有用户的多个VM的逻辑交换元件，在提供L3网关服务的传输节点中实现逻辑路由器。在逻辑交换元件中创建逻辑修补端口，以将逻辑路由器链接到逻辑交换元件。在一些实施例中，创建逻辑修补以及提供VM的顺序对隧道创建没有关系。逻辑修补端口的创建导致逻辑控制器将通用隧道流指令发送到连接实现逻辑交换元件的所有管理交换元件(即，每一个都具有逻辑交换元件的逻辑端口被映射到的至少一个端口的所有管理交换元件)机箱控制器(或物理控制器)。这些管理交换元件中的每一个的每一机箱控制器都指示管理交换元件创建到传输节点的隧道。管理交换元件各自创建到传输节点的隧道，导致与实现逻辑交换元件的管理交换元件的数量相同的许多隧道。

如果这些隧道是单向的，则传输节点将创建到实现逻辑交换元件的管理交换元件中的每一个的隧道。当逻辑修补端口被创建并连接到逻辑路由器时，逻辑交换元件将通用隧道流指令推送到传输节点。连接传输节点的机箱控制器指示传输节点创建隧道，传输节点创建到管理交换元件的隧道。

在一些实施例中，在管理交换元件之间建立的隧道可以用于附接到管理交换元件中的一个的任何机器和附接到另一个管理交换元件的任何机器之间的数据交换，不管这两个机器是否正在使用同一个逻辑交换元件或两个不同的交换元件的逻辑端口。这是隧道使得正在管理不同LDP集合的不同用户能够共享管理交换元件同时被隔离的一种示例情况。

当逻辑端口附接到L2网关服务时，两个管理交换元件之间的隧道的创建开始，其中，逻辑端口和附接到L2网关服务的另一逻辑端口。附接导致逻辑控制器向实现逻辑交换元件的其他逻辑端口的所有管理交换元件发出通用隧道流指令。基于指令，建立从这些管理交换元件到实现附接到L2网关服务的逻辑端口的管理交换元件的隧道。

III.电子系统

上文所描述的特点和应用中的许多被实现为被指定为记录在计算机可读存储介质(也被称为计算机可读介质)上的指令集的软件进程。当这些指令由一个或多个处理单元(例如，一个或多个处理器、处理器的核，或其他处理单元)执行时，它们导致处理单元执行在指令中所指出的动作。计算机可读介质的示例包括，但不仅限于，CD-ROM、闪存驱动器、RAM芯片、硬盘驱动器、EPROM等等。计算机可读介质不包括以无线方式或通过有线连接传递的载波和电子信号。

在此说明书中，术语“软件”意味着包括驻留在只读存储器中的固件或存储在磁存储器中的可以被读取到存储器中供处理器进行处理的应用。此外，在一些实施例中，多个软件发明可被实现为较大的程序的子部分，同时保持不同的软件发明。在一些实施例中，多个软件发明也可以被实现为单独的程序。最后，一起实现这里所描述的软件发明的单独的程序的任何组合都在本发明的范围内。在一些实施例中，软件程序，当被安装以在一个或多个电子系统上操作时，定义执行软件程序的操作的一个或多个特定机器实现。

图23在概念上示出了用来实现本发明的一些实施例的电子系统2300。电子系统2300可以用来执行上文所描述的控制、虚拟化、或操作系统应用中的任何一种。电子系统2300可以是计算机(例如，台式计算机、个人计算机、平板电脑、服务器计算机、大型机、刀片式计算机等等)、电话、PDA，或任何其他种类的电子设备。这样的电子系统包括各种类型的计算机可读介质和用于各种其他类型的计算机可读介质的接口。电子系统2300包括总线2305、处理单元2310、系统存储器2325、只读存储器2330、永久存储器设备2335、输入设备2340，以及输出设备2345。

总线2305共同地代表可通信地连接电子系统2300的很多内部设备的所有系统、外围，以及芯片集总线。例如，总线2305可通信地将处理单元2310与只读存储器2330、系统存储器2325、以及永久存储器设备2335连接。

从这些各种存储器单元，处理单元2310检索要执行的指令和要处理的数据，以便执行本发明的处理。在不同的实施例中，处理单元可以是单处理器或多核处理器。

只读存储器(ROM)2330存储由处理单元2310及电子系统的其他模块需要的静态数据以及指令。另一方面，永久存储器设备2335是读取-写入存储器设备。此设备是即使在电子系统2300关闭的情况下也能存储指令和数据的非易失性存储器单元。本发明的一些实施例使用大容量存储器(诸如磁盘或光盘以及其对应的磁盘驱动器)作为永久存储器设备2335。

其他实施例使用可移动存储器设备(诸如软盘、闪存驱动器等等)作为永久存储器设备。类似于永久存储器设备2335，系统存储器2325是读取-写入存储器设备。然而，与存储设备2335不同，系统存储器是易失性读取-写入存储器，诸如随机存取存储器。系统存储器存储处理器在运行时需要的某些指令和数据。在一些实施例中，本发明的处理存储在系统存储器2325、永久存储器设备2335，和/或只读存储器2330中。从这些各种存储器单元，处理单元2310检索要执行的指令和要处理的数据，以便执行一些实施例的处理。

总线2305还连接到输入和输出设备2340和2345。输入设备使得用户能够将信息和选择命令传递到电子系统。输入设备2340包括字母数字键盘和指示设备(也叫做“光标控制设备”)。输出设备2345显示由电子系统所生成的图像。输出设备包括打印机和诸如阴极射线管(CRT)或液晶显示器(LCD)之类的显示设备。一些实施例包括诸如充当输入和输出设备的触摸屏之类的设备。

最后，如图23所示，总线2305还通过网络适配器(未示出)将电子系统2300耦合到网络2365。如此，计算机可以是计算机网络(诸如局域网(“LAN”)、广域网(“WAN”)，或内联网，或诸如因特网的网络的一部分。电子系统2300的所有组件可以和本发明一起使用。

一些实施例包括电子组件，诸如微处理器，在机器可读的或计算机可读介质(可替选地被称为计算机可读取的存储介质、机器可读取的介质，或机器可读的存储介质)中存储计算机程序指令的存储器。这样的计算机可读介质的一些示例包括RAM、ROM、只读紧凑光盘(CD-ROM)、可记录紧凑光盘(CD-R)、可重写的紧凑光盘(CD-RW)、只读数字通用光盘(例如，DVD-ROM、双层DVD-ROM)、各种可记录/可重写DVD(例如，DVD-RAM、DVD-RW、DVD+RW等等)、闪存(例如，SD卡、微型SD卡、微SD卡等等)、磁性和/或固态硬盘驱动器、只读和可记录

光盘、超密度光盘、任何其他光学或磁性介质，以及软盘。计算机可读介质可以存储可由至少一个处理单元执行的并包括用于执行各种操作的指令集的计算机程序。计算机程序或计算机代码的示例包括机器代码，诸如由编译器所产生的机器代码,以及包括由计算机执行的较高级别的代码的文件，电子组件，或使用解释器的微处理器。

尽管上面的讨论主要引用了执行软件的微处理器或多核处理器，但是，一些实施例是由诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA)之类的一个或多个集成电路执行的。在一些实施例中，这样的集成电路执行存储在电路本身上的指令。

如本说明书中所使用的，术语“计算机”、“服务器”、“处理器”，以及“存储器”都是指电子或其他技术设备。这些术语排除人或人的组。对于说明书，术语“显示”表示显示在电子设备上。如此说明书中所使用的，术语“计算机可读介质”，以及“机器可读的介质”完全局限于以可由计算机读取的形式存储信息的有形的物理对象。这些术语排除任何无线信号、有线下载信号，以及任何其他短暂的信号。

尽管本发明是参考很多具体细节来描述的，但是，那些精通本技术的普通人员将认识到，在不偏离本发明的精神的情况下，本发明可以以其他特定形式来实现。另外，若干个图(包括图20和21)在概念上示出了处理。这些处理的特定操作可以不以所示出和所描述的准确的顺序执行。特定操作可以不以连续的操作系列执行，而不同的特定操作可以在不同的实施例中执行。此外，处理还可以使用多个子处理，或作为较大的宏处理的一部分来实现。

此外，上文还描述了其中用户根据LCP数据提供LDP集合的多个实施例。然而，在其他实施例中，用户可以根据LFP数据提供LDP集合。另外，上文还描述了其中控制器实例向交换元件提供PCP数据以便管理交换元件的多个实施例。然而，在其他实施例中，控制器实例可以给交换元件提供物理转发平面数据。在这样的实施例中，关系数据库数据结构将存储物理转发平面数据，而虚拟化应用将生成这样的数据。

此外，在上面的多个示例中，用户指定一个或多个逻辑交换元件。在一些实施例中，用户可以提供物理交换元件配置以及这样的逻辑交换元件配置。此外，尽管描述了在一些实施例中是分别地由在一个计算设备上执行的多个应用层形成的控制器实例，但是，如那些精通相关技术的人所认识的，这样的实例是由专用计算设备或在一些实施例中是由执行一层或多层它们的操作的其他机器形成的。

此外，上文所描述的多个示例还示出了LDPS与一个用户相关联。那些精通本技术的普通人员将认识到，在一些实施例中，用户可以与一组或多组LDP集合相关联。即，LDPS和用户之间的关系并不总是一对一关系，因为一个用户可以与多个LDP集合相关联。如此，那些精通本技术的普通人员将理解，本发明将不受前述的说明性细节限制。

Claims (20)

1.一种用于在托管系统的主机计算机上执行的控制器应用的用于控制也在所述主机计算机上执行的受管理的转发元件的转发行为的方法，所述方法包括：

接收定义逻辑网络的逻辑转发元件的转发行为的数据，其中所述逻辑网络将连接到所述受管理的转发元件的、特定用户的机器集合逻辑连接到被连接到多个其他受管理的转发元件的、所述特定用户的多个其他机器；

基于接收到的数据，生成用于定义所述受管理的转发元件的转发行为的数据以实现所述逻辑转发元件；以及

将所生成的数据分发给所述受管理的转发元件以连同所述多个其他受管理的转发元件实现所述逻辑转发元件。

2.如权利要求1所述的方法，其中所述受管理的转发元件通过将所述逻辑转发元件的一个或多个逻辑端口映射到所述受管理的转发元件的所述机器集合被耦接到的一个或多个端口来实现所述逻辑转发元件。

3.如权利要求1所述的方法，还包括从所述受管理的转发元件接收关于受管理的转发元件的数据，其中定义所述受管理的转发元件的转发行为的数据基于(i)接收到的定义所述逻辑转发元件的转发行为的数据以及(ii)从受管理的转发元件接收到的关于受管理的转发元件的数据来生成。

4.如权利要求3所述的方法，其中所述从受管理的转发元件接收到的关于受管理的转发元件的数据包括所述逻辑转发元件的逻辑端口被映射到的所述受管理的转发元件的端口号。

5.如权利要求3所述的方法，其中所述从受管理的转发元件接收到的关于受管理的转发元件的数据包括关于在所述机器集合中在所述主机计算机上执行的机器的故障的数据。

6.如权利要求1所述的方法，其中接收到的数据是从与所述主机计算机分开的控制器计算机接收的，其中所述控制器计算机将数据分发到(i)在所述主机计算机上执行的所述控制器应用以及(ii)在其他主机计算机上执行的多个其他控制器应用。

7.如权利要求6所述的方法，其中所述其他控制器应用中的每个控制器应用(i)基于来自所述控制器计算机的数据来生成定义在所述其他控制器应用在其上执行的所述其他主机计算机上执行的对应的受管理的转发元件的转发行为的自定义数据，以及(ii)将所生成的自定义数据分发到所述对应的受管理的转发元件以实现所述逻辑转发元件。

8.如权利要求1所述的方法，其中所述受管理的转发元件连同所述多个其他受管理的转发元件通过与所述其他受管理的转发元件交换网络数据来实现所述逻辑转发元件，其中所述网络数据由被逻辑连接到所述逻辑转发元件的所述机器发送到所述受管理的转发元件或者从所述受管理的转发元件接收。

9.如权利要求1所述的方法，其中所述逻辑转发元件是第一逻辑转发元件，所述特定用户的机器集合是第一用户的第一机器集合，所述多个其他机器是第一用户的第一多个其他机器，并且所述逻辑网络是第一逻辑网络，所述方法还包括：

接收定义第二逻辑网络的第二逻辑转发元件的转发行为的数据，其中所述第二逻辑网络将连接到受管理的转发元件的、第二用户的第二机器集合逻辑连接到被连接到所述多个其他受管理的转发元件的、第二用户的第二多个其他机器；

基于所接收到的数据，生成用于定义所述受管理的转发元件的转发行为的数据以还实现所述第二逻辑转发元件；以及

将所生成的数据分发给所述受管理的转发元件以连同所述多个其他受管理的转发元件实现所述第二逻辑转发元件。

10.如权利要求9所述的方法，其中所述第一逻辑网络属于所述托管系统的所述第一用户，而所述第二逻辑网络属于所述托管系统的不同的所述第二用户。

11.一种在托管系统的主机计算机上执行的用于控制也在所述主机计算机上执行的受管理的转发元件的转发行为的控制器应用系统，所述系统包括：

用于接收定义逻辑网络的逻辑转发元件的转发行为的数据的装置，其中所述逻辑网络将连接到受管理的转发元件的、特定用户的机器集合逻辑连接到被连接到多个其他受管理的转发元件的、所述特定用户的多个其他机器；

用于基于接收到的数据，生成用于定义所述受管理的转发元件的转发行为的数据以实现所述逻辑转发元件的装置；以及

用于将所生成的数据分发给所述受管理的转发元件以连同所述多个其他受管理的转发元件实现所述逻辑转发元件的装置。

12.如权利要求11所述的系统，其中所述受管理的转发元件通过将所述逻辑转发元件的一个或多个逻辑端口映射到所述受管理的转发元件的所述机器集合被耦接到的一个或多个端口来实现所述逻辑转发元件。

13.如权利要求11所述的系统，还包括用于从所述受管理的转发元件接收关于受管理的转发元件的数据的装置，其中定义所述受管理的转发元件的转发行为的数据基于(i)接收到的定义所述逻辑转发元件的转发行为的数据以及(ii)从受管理的转发元件接收到的关于受管理的转发元件的数据来生成。

14.如权利要求13所述的系统，其中所述接收到的关于受管理的转发元件的数据包括所述逻辑转发元件的逻辑端口被映射到的所述受管理的转发元件的端口号。

15.如权利要求13所述的系统，其中所述接收到的关于受管理的转发元件的数据包括关于在所述机器集合中在所述主机计算机上执行的机器的故障的数据。

16.如权利要求11所述的系统，其中定义所述逻辑转发元件的转发行为的数据是从与所述主机计算机分开的控制器计算机接收的，其中所述控制器计算机将数据分发到(i)在所述主机计算机上执行的所述控制器应用以及(ii)在所述其他主机计算机上执行的多个其他控制器应用。

17.如权利要求16所述的系统，其中所述其他控制器应用中的每个控制器应用(i)基于来自所述控制器计算机的数据来生成定义在所述其他控制器应用在其上执行的所述其他主机计算机上执行的对应的受管理的转发元件的转发行为的自定义数据，以及(ii)将所生成的自定义数据分发到所述对应的受管理的转发元件以实现所述逻辑转发元件。

18.如权利要求11所述的系统，其中所述受管理的转发元件连同所述多个其他受管理的转发元件通过与所述其他受管理的转发元件交换网络数据来实现所述逻辑转发元件，其中所述网络数据由被逻辑连接到所述逻辑转发元件的所述机器发送到所述受管理的转发元件或者从所述受管理的转发元件接收。

19.如权利要求11所述的系统，其中所述逻辑转发元件是第一逻辑转发元件，所述特定用户的机器集合是第一用户的第一机器集合，所述多个其他机器是第一用户的第一多个其他机器，并且所述逻辑网络是第一逻辑网络，其中所述系统还包括：

用于接收定义第二逻辑网络的第二逻辑转发元件的转发行为的数据的装置，其中所述第二逻辑网络将连接到受管理的转发元件的、第二用户的第二机器集合逻辑连接到被连接到所述多个其他受管理的转发元件的、第二用户的第二多个其他机器；

用于基于所接收到的数据，生成用于定义所述受管理的转发元件的转发行为的数据以还实现所述第二逻辑转发元件的装置；以及

用于将所生成的数据分发给所述受管理的转发元件以连同在所述多个其他主机机器上执行的所述多个其他受管理的转发元件实现所述第二逻辑转发元件的装置。

20.一种机器可读介质，所述机器可读介质存储控制器应用，所述控制器应用当由至少一个处理单元执行时执行如权利要求1-10中任一项所述的方法。

Images