SDN控制器

　　SDN控制器就像是一个整个架构的中间件。控制器必须整合网络中所有物理和虚拟设备。控制器会从与设备一起工作的SDN软件中提取物理网络设备。控制器与网络设备之间高度融合。在OpenFlow环境中，控制器会使用OpenFlow协议和NETCONF协议与交换机联系。(OpenFlow是将流数据发送到交换机的API，而NETCONF是网络配置API。)

　　SDN：基础架构

　　在当前SDN方法中，供应商只是把应用和控制器作为单独产品提供。例如，Nicira/VMware将其应用和控制器打包到了一个单独的专属应用堆栈中。思科则通过把控制器嵌入IOS软件的方式把控制器打包到了OnePK产品中。笔者也希望思科可以在近期推出一款有分量的控制器。Big Switch Networks最近发布了SDN控制器的商用版，该产品提供的两个应用(Big Virtual Switch和Big Tap)运行于控制器之上。

　　显然，控制器是网络架构中的关键要素。它必须把API显示给代表着可用功能的应用，而SDN战场上这一部分的角逐也最激烈。

　　SDN API：新的战场

　　一个SDN架构包含两个截然不同的网络API：北向和南向。OpenFlow是一个北向API。OpenFlow描述了一个行业标准API，这个API在以太网交换机中配置了帧转发芯片 并且定义了网络中的数据流路径。此外，开放网络基金会(ONF)作为监督OpenFlow协议的标准组织发布了一个用于设备配置的API，其名称为OF-CONFIG。OF-CONFIG使用NETCONF XML数据格式定义语言。

　　思科的OnePK是南向API。关于OpenFlow是否能满足网络需求有些争议，特别是从基于数据包的网络转向基于数据流的网络。一些悬而未决的问题会影响到这种过渡，如与现有协议STP或OSPF的互操作性问题。

　　北向和南向API

　　北向API在SDN架构中提供了一种机制呈现服务或应用。每个应用都会为网络设备开发出一个流量表视图，然后将请求发送给控制器获取网络设备的配额。

　　例如，一个虚拟交换应用应能够在物理和虚拟机网络的所有连接点上创建一个网络图表/数据库。在多租户的以太网中，应用可以开发一套流量规则模拟以太网VLAN，同时保持每位租户浏览的独立性。流量规则应该包含进出端口的数值，加上始发MAC地址和目的地MAC地址。

　　北向API，从服务到控制器都还未被定义。笔者认为可以归结为三个原因。第一，大厂商还不能找到有力的使用案例足以说服他们投资。第二，只有少部分控制器上市，还未有证据显示它们是强大的生产平台。第三，不同的应用或许要依据各自的情况通过不同API访问控制器。例如，一个防火墙应用或许需要高性能，低延时，低复杂度的数据交换，同时监控应用只需读取途经的数据。

　　整个行业面临多种选择。似乎ONF中会有一些论坛在不久后将推出一些指导，而IETF也通过Network Working Group发布了一些草案。

　　缺乏标准的API意味着软件开发者不得不对开发平台做出选择。F5 是为思科还是Big Switch的控制器做研发呢?安全公司为OpenFlow开发防火墙又会怎样?他们会选择惠普OpenFlow控制器还是为IBM呢?北向API必须形成一定的标准，但是其格式，性能和数据结构或许无法很好地被理解。所以在这个方面还需要有更多努力。