软件定义网络潜在用户所面临的一个关键挑战是判断特定SDN控制器的特定价值，毕竟控制器作为网络应用和网络基础设施之间的桥梁发挥着关键性作用。但目前还没有一个可以规范SDN的模型，也没有一个SDN控制器必须要遵守的任何标准。
SDN控制器设计要素
显而易见，SDN控制器是整个SDN网络的核心，因此其设计需要综合考虑等方面的需求，具体来说，其设计的核心要素如下图所示：
在这些SDN控制器的核心能力中，有些是传统网络设备已经给与了关注的，例如扩展性、性能、安全性、集中监控及可视化、可靠性等。同时，也有一些是专门面向SDN网络的，例如OpenFlow支持，网络虚拟化和网络编程能力等。
应当关注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)通信意味着传输控制平面的流量需要一个独立的物理网络。
带内通信受到了一些希望通过“可达性”调整网络拓扑的厂商们的支持。这一方案的理念是，如果网络设备不再能够被控制器控制，那么拓扑将会发生调整，控制器能够发现这些变化并做出相应调整。带外通信也受到了一些厂商的支持。这部分厂商主要是希望确保控制器之间和交换机之间的低延迟，提升安全性，消除控制平面流量丢失所造成的数据流量风险。
第二个关于中央控制器的顾虑是这些控制器将被实现中央化控制的方式。智能化中央化控制并不一定意味只有一个物理设备或是一组冗余设备来担当SDN控制器。许多厂商将控制平面功能分散至能够相互通信并共享数据库的分布式虚拟机当中。这些组件可能会向控制器软件的核心部分反馈信息，但是也有可能是向虚拟机反馈信息。物理控制器或控制器集群，以及履行控制平台职责的分布式虚拟机这几种模式在目前的SDN产品当中都存在。
能力
值得注意的是，并非所有SDN控制器都具有相同的能力。这里的能力并不是指控制器流安装等原始性能，而是指控制器对网络的实际操控能力。大部分网络运营者并不仅仅寻找一款OpenFlow控制器，而是希望它让尽可能多的网络元素配置实现自动化。此时，你需要问厂商以下一些问题，包括：
·这一控制器将与哪些设备进行对话?你需要知道，这一控制器是否除了与网络交换机对话外，还可以与防火墙、负载均衡设备、虚拟交换机、云编排工具以及其他设备对话。
·该供应商拥有哪些合作关系?许多SDN控制器厂商都与主要的网络厂商建立了战略同盟关系。这些合作使得SDN控制器与合作厂商的工具之间更容易通信。不过，并非所有的SDN厂商都有着相同的合作关系。因此在评估SDN控制器时，搞清楚该厂商拥有哪些合作关系，以及这些合作关系促成了哪些合作成果非常关键。
·现有应用都有哪些?一些SDN控制器更像是一个空白的画板——能够展示任何东西，但是首先需要有人在上面作画才行。另有一部分SDN控制器已经建立了其应用生态环境——有人已经在上面为你画了非常漂亮的画。搞清楚其现在都有些什么应用，对于你决定让SDN控制器在网络中发挥多大作用将大有帮助。
·控制器的API是否已经被明确?API是从控制器中获取和向控制器发送信息的机制，网络应用程序会通过北向API告诉控制器它们需要什么。API是自动化和编配的关键。例如，你的机构能够以多高的效率利用控制器API?对于正在寻求整体解决方案的用户，他们可能并不关心这个。但是对于那些希望编写自己的网络应用程序的用户来说，这一点非常关键。
开放vs.厂商锁定
传统的网络协议在厂商之间具有很大程度的互操作性。例如，一家厂商的使用BGP协议的设备也可以被其他厂商使用BGP协议的设备所理解。虽然厂商可能会在协议中增加一些私有特性，但是在基本上通用网络设备厂商都会遵守一条底线。
在SDN方面，情况却并非如此。目前还没有创建SDN控制器的统一方式，也没有一套关于SDN必须具备哪些功能的要求。接触的控制器和架构越多，你就越会发现它们之间存在着相当大的差异。这些都是意料之中的事情。由于SDN还是一项新兴技术，因此厂商都在发布能够代表其SDN观念的控制器，以尽可能地在市场中突出自己，从而力争成为市场***。
对于用户来说，由于缺乏标准，导致他们在控制器采购中遇到了许多尴尬问题。首先是这个控制器是不是将你套牢在一个特定解决方案当中?这是一个需要回答的重要问题。尽管许多SDN解决方案都具有强大的能力，但是它们可能只针对特定类型的用户，帮助他们解决某一单一问题。虽然目前这一解决方案可能会为你带来优势，但是未来它们可能会成为你的包袱。例如，若干年后你可能会更换你的负载平衡设备供应商以减少运营支出，但是SDN控制器及其相关应用可能无法与其他厂商开发的负载平衡设备协同工作。厂商锁定隐藏的风险值得我们在决策时谨慎考虑。
·用户能够转而使用其他的控制器吗?如果能，过渡应当如何进行?表面看来，这与其他的顾虑没有太多的不同。例如，从路由器供应商A更换至供应商B需要对产品的功能和操作性进行考虑——B供应商的产品能否满足你的要求?你的网络团队能否管理B供应商的路由器?但在SDN控制器方面，更换供应商的挑战更为复杂。这需要回到控制器究竟在为你做什么这一概念上来看。标准遵从性可以极大地降低更换路由器厂商所存在的风险，但是在SDN领域中，还没有类似的标准出台。你的网络应用是否能够与不同的控制器协同工作?如果不进行适当修改，那么为某一控制器编写的应用很可能无法在其他控制器上工作。或许OpenDaylight组织能够改变这一现状，但是目前网络用户必须要花时间了解SDN控制器，以搞清楚是否自己在某些地方被厂商锁定了。
总之，购买SDN控制器并不是一件无关紧要的小事。此类投资不仅仅需要了解控制器的能力和性能，还需要搞清楚控制器是如何解决特定网络问题的。在添加SDN控制器之前你必须要熟悉自己的网络功能。花些功夫进行研究对防止大的投资失误很有帮助。
