3.1 SDN控制器
如后面的图3-1所描绘的那样，在软件定义网络（SDN）中，特别是OpenFlow中，控制平面和数据平面是分离的，我们可以把两者类比作操作系统和计算机硬件，OpenFlow控制器（就好比操作系统）提供一个OpenFlow交换机（就好比计算机硬件）的编程接口，利用这个编程接口，就可以开发网络应用，完成控制和管理任务，并提供新的功能。SDN中的控制平面，特别是OpenFlow的控制平面，在逻辑上是集中化的，因此在开发网络应用的时候，可以把网络视为一个系统。
由于采用应变式的（reactive）控制模型，每当需要做出决策时，OpenFlow交换机都必须询问OpenFlow控制器，比如，当一个新的数据包流到达OpenFlow交换机（即发生Packet_in事件）时。由于采用基于流的控制粒度，每当把一个新的流的第一个数据包转发给控制器进行决策（例如，询问转发还是丢弃）时，都会由于延迟带来性能上的些微下降，而该流中的后续数据包流量将会以交换机硬件的线速转发。尽管在很多情况下，第一个数据包的延时是可以忽略不计的，但是，如果中心控制器在地理上相距较远，大多数流的持续时间又比较短暂的话（譬如，仅由一个数据包所构成的流），就有可能是一个值得关注的问题。在OpenFlow中，还可以采取另一种主动式的（proactive）解决方案，就是将决策的策略规则从控制器推送到交换机中。
图3-1 SDN解决方案中控制器的作用
尽管这种模式简化了控制、管理和策略的执行，然而却必须在控制器和OpenFlow交换机之间维持一个严格的绑定关系，这种集中式的控制方式带来的第一个需要重视的问题就是系统的可扩展性，第二个问题是控制器的部署位置。根据目前多OpenFlow控制器实现方案（NOX-MT、Maestro和Beacon）的研究结果，在一个包括100 000台主机和多达256台交换机的大规模仿真网络上，经多次不同实验证明，所有的OpenFlow控制器都能够以至少每秒50 000个新的流请求的处理速度运行。此外，新型OpenFlow控制器目前也在研发中，如Mc-Nettle（http://haskell.cs.yale.edu/nettle/mcnettle/），它定位于超强的多核多服务器，能承担大型数据中心规模的负载流量（譬如每秒2千万个流请求，并可扩展至5000台交换机）。在传统的数据包交换网络中，每个数据包中都包含了交换机为数据包进行路由决策所需要的信息，然而，大多数应用程序所发送的数据都是由多个数据包所组成的数据流，而OpenFlow的控制粒度就是基于流，而不是数据包的，在数据平面（OpenFlow交换机）上，当对一个流进行控制时，基于流的第一个数据包所做出的决策可以施加于流中后续的所有数据包。通过将流进行组合，还可以进一步减小开销，比如，将两台主机之间的所有流量聚合，然后对汇聚的流实施控制决策。
在部署OpenFlow（以及SDN）时，可以采用多控制器来降低延时，提高可扩展性和容错性。OpenFlow允许将多个控制器与一个交换机相连接，这样，当发生失效事件时，后备控制器可以进行切换。在这个方面，Onix和HyperFlow作了进一步的尝试，其解决方案维持了一个逻辑上集中而物理上分布的控制平面。通过启动本地控制器之间的相互通信，降低查表的开销，而对应用程序写入时，依然能够维持一个简化的、集中式的网络视图。这种方案主要存在这样一个潜在问题，即需要在整个分布式系统中维持一致的状态，一旦不能维持全局网络状态的一致性，而网络应用仍以为自己的网络视图是正确的，它就会对当前网络状态作出不正确的反应。
回顾我们之前提到的有关操作系统的类比，一个网络控制器发挥着网络操作系统的作用，它至少需要实现两个接口：允许OpenFlow交换机和控制器通信的南向接口，以及为网络的控制和管理应用提供的应用编程接口（API），即北向接口。目前已有的南向接口是OpenFlow协议（见第2章），它是SDN南向接口的早期实现方案。外部的控制管理系统或者网络服务可能需要提取底层网络的相关信息、执行某些策略，或者控制网络行为的某个方面。此外，主OpenFlow控制器可能需要跟后备控制器共享策略信息，或者跨多个不同的控制域与其他控制器通信，虽然对于南向接口已有明确的定义（如OpenFlow或ForCES，参见http://datatracker.ietf.org/wg/forces/charter/），可以把它视为事实上的标准，然而，目前还没有被广泛认可的北向交互标准，人们仍倾向于从特定应用的用户用例出发实现北向接口。