软件定义网络潜在用户所面临的一个关键挑战是判断特定SDN控制器的特定价值，毕竟控制器作为网络应用和网络基础设施之间的桥梁发挥着关键性作用。但目前还没有一个可以规范SDN的模型，也没有一个SDN控制器必须要遵守的任何标准。

　　虽然Linux基金会旗下的多厂商OpenDaylight项目的出现为统一的模块化控制器架构所需的SDN堆栈带来了希望，但是对于控制器需要提供什么样的特定服务，厂商当中仍然存在着许多不同的意见。用户的压力在于确定SDN控制器具有什么样的能力，以及这些功能是否能够帮助实现期望的目标。即便如此，消费者也难以购买到一个独立的SDN控制器。实际情况是厂商常常将控制器捆绑在整个SDN套装之中，这个套装通常包括：应用软件、控制器和网络硬件。

　　即便你考虑从厂商那里购买一个整体解决方案，控制器的功能也可能出现麻烦。毕竟，软件定义网络正在迅速发展，而最初的整体解决方案会显得陈旧。因此我们有众多的因素需要考虑，细述如下。

　　原始性能

　　谈到原始性能，我们首先需要明确SDN控制器的作用。通常，SDN控制器的功能是将网络环境中的控制与数据平面互相分离。换句话说，控制器将告诉网络设备如何转发流量(控制平面)，但是它们并不真正转发这些流量(数据平面)。这种情况在OpenFlow(OF)网络中非常常见。在OpenFlow网络中，SDN控制器主要用于对网络设备中的OF表单进行编程。

　　在OpenFlow网络中，OF交换机接收数据包并根据流表处理这些数据包。但是如果流表中的数据包没有匹配的条目，将会怎样?在这种情况下，OF交换机将把数据包发给OF控制器，这实际上相当于在问“我应该怎么处理这些数据包?”。OF控制器来决定当数据包与流匹配时交换机应当做些什么，并对交换机进行编程。这一程序被称为“流安装”。

　　由于扩展方面的需求，SDN控制器每秒的流安装量受到了高度重视。通常，流安装在SDN中会存在一个性能瓶颈。但是不要想当然的认为，在大量交换机和你希望控制的庞大微流数量共同作用下，它们很快就会超过控制器流安装能力。必须牢记并不是每个流都需要与控制器联系。只有那些还没有被识别或编程的流才需要这一步骤，而这通常只是例外情况。

　　对于厂商来说，他们非常清楚OpenFlow网络的流安装性能所带来的挑战。厂商们已经制订了许多缓解控制器瓶颈的策略。因此不要因为原始性能数据不佳就简单地将某一控制器选择排除在外。厂商可能有办法优化你的网络环境，将流安装的需求量降到最低限度。在这些缓解办法当中，有一种名为流通配符。该允许通过一个单一的流条目处理众多微流。

　　拓扑

　　在评估SDN控制器时另一个要考虑因素是你的网络拓扑。让我们先考虑一下LAN和WAN的区别。你想用软件定义网络中的哪一部分?尽管LAN是典型的SDN使用案例，但是如果你希望横跨WAN部署网络虚拟化，那会是什么情况?控制器在这一模式中将如何工作?这在很大程度上是一个有关功能性的问题。当你的SDN环境对于单个控制器来说显得过大因而无法有效管理时，供应商会提供什么样的选项帮助你向广域网扩展?

　　采用中央控制器方式的SDN解决方案可以进行横向扩展。换句话说，你可以增加控制器以应对额外的交换机。不过这里存在一个非常棘手的问题，这些交换机彼此之间将如何进行通信。

　　对此，厂商给出了许多种答案。尽管业内很早就展开了对控制器彼此对话方式进行标准化的讨论，但是在大多数情况下，目前的解决方案还只是局限于特定的控制器。一个常见的技术组合是通过BGP协议实现控制器之间的信息交换。在这种方式中，控制器知道如何查找网络中不同的软件定义部分，并在两个区域之间转发流量。如果这一功能对你来说非常重要，那么你需要向备选的供应商询问这个关键性问题。

　　虽然许多SDN解决方案能够支持一个中央控制器，但是中央化控制器的概念仍然存在一个潜在的问题。首先是控制平面的流量(如从控制器到网络交换机的指令)如何被传输。带内通信意味着控制平面的流量将使用所有正常网络流量所使用的路径，带外(OOB)通信意味着传输控制平面的流量需要一个独立的物理网络。

　　带内通信受到了一些希望通过“可达性”调整网络拓扑的厂商们的支持。这一方案的理念是，如果网络设备不再能够被控制器控制，那么拓扑将会发生调整，控制器能够发现这些变化并做出相应调整。带外通信也受到了一些厂商的支持。这部分厂商主要是希望确保控制器之间和交换机之间的低延迟，提升安全性，消除控制平面流量丢失所造成的数据流量风险。