从2009年业内***次提出SDN概念开始算起，到今年已是第6个年头;从2011年开放网络基金会(ONF，Open Networking Foundation)成立开始计算，也已是第4个年头。相对于往年SDN的热炒，2014年无疑显得略微平淡，但是这一年SDN的商用进程悄悄加速，越来越多的厂商推出商用或试商用产品，也有更多的客户开始进行SDN部署或POC测试。
另外一方面，开源社区在SDN商用发展中所起到的作用也越来越显著：OpenDayLight(ODL)发布了氦版本，在集群以及SAL架构上做了很大的改进;ONLab推出了酝酿已久的ONOS开源SDN控制器，Open vSwitch(OVS)也加快了对OpenFlow协议的支持，从2.3版本开始正式全面支持OpenFlow 1.3以及OpenFlow 1.4部分特性;越来越多的SDN方案被用于OpenStack等云管理系统的网络底层实现方式。
相比之下，在SDN的ASIC芯片支持上进展相对缓慢。这使得数据中心主流的解决方案仍然是以Overlay方案为主，硬件交换机和控制器多厂商互通方案仍然离商用尚有距离。在非OpenFlow的SDN领域，厂商私有解决方案进展或许较快，无论是思科的ACI方案还是VMWare的NSX都赢得了一定的眼球。
在电信运营商领域，2014年有不少基于SDN的回传网络、光传输、CPE和流量优化等POC测试的发布，但是实际上它们大多都是基于现有产品的部分开放接口或集中管控改造的实验产品，很大程度上是已有技术的演进——包括基于边缘网络虚拟化、PCE技术乃至网络管理技术的演进。在运营商网络中，稳定可靠、性能的要求要高于灵活性，引入标准意义上SDN的门槛被抬高，而客户价值降低，这使得运营商在基础网络上始终属于技术上的保守派。可类比的实例是，2009年就有不少运营商开始评估测试电信网元的虚拟化，但是时至今日，NFV的大热才真正开启了运营商基础网络设施的虚拟化应用进程。
SDN的路线之争
SDN作为一种网络集中管控、开放接口的理念在ONF不遗余力的推广下得到业界认同，但是到底采用什么样的技术路线，却因为厂商观点和利益立场的原因并没有快速收敛，反而因为思科ACI解决方案、OpenDayLight开源项目影响力增加而日趋模糊。
从OpenFlow的理念来看，其将智能全部汇聚于集中的控制器，而转发面机械地执行转发指令即可，因而完全同质化。这样势必导致目前在网络产业中占据主要市场份额的硬件设备市场进入门槛大大降低，主导厂商地位因此受到威胁。他们从一开始抗拒SDN，继而拥抱SDN理念，然后力推和OpenFlow有显著差异的解决方案。
从已有的厂商SDN解决方案来看，绝大部分都在南向接口上支持OpenFlow 1.0或1.3，但是不少厂商都同时拥有自己的私有协议接口或已有IETF协议的变种，比如ONEPK，OpFlex，BGP、XMPP、NetConf和私有的RESTful接口。
当然出于市场推广的需要，他们基本都会声称是完全开放的接口，甚至会在IETF进行部分的标准化推进。这些方案和OpenFlow的根本性区别在于转发面仍然是自在的网络，脱离集中的控制器仍然可以运行基本转发业务，只开放通过API控制、影响部分转发面智能逻辑的能力，从而保留了硬件设备的差异化竞争能力。而ONF的架构文档中特别标明，SDN控制器必须具备对转发面的完全控制权，从而将此类方案统统划归在了“伪SDN”的范畴。
即使排除厂商的利益因素，单纯从技术角度来看，OpenFlow的完全控制转发分离架构对协议体系成熟度、控制器产品的实现难度而言更高。一个离开逻辑上集中的控制器就无法运转的网络架构，本身就蕴含了额外的风险和成本。类似的场景是上个世纪90年代初电信网络在由随路信令向共路信令迁移的过程中，运营商新建设了一个更加可靠的控制平面来解决这个问题(当然其驱动力还包含信令数字化后带来信令容量提升、更快的接续速度、新业务支持等优势)。而在SDN的初期推广过程中，对于已有网络的SDN改造就面临额外支出的控制平面成本问题。如果初期SDN带来的收益不足以让客户付出此部分额外的成本，则部署本身可能会从反面证明SDN的可靠性的确存在问题。
另外一方面，OpenFlow持续增长的复杂性也引起了产业界的顾虑。为了兼顾各种场景，OpenFlow必须在协议中增加对不同报文格式以及操作指令的支持，这使得ASIC来支持完全的OpenFlow标准越来越困难。为此ONF推出了可协商数据平面模型(NDM)的规范。在此规范下，OpenFlow可以支持特定ASIC能力的控制，但是其需要在控制器上增加相应的硬件驱动程序。即使抛却基本不可实现的理想全标准化NDM模型，也还意味着如果要实现完全互通，工作量和转发硬件数量*控制器数量正相关，每一种硬件都需要在一种控制器上实现一种驱动——除非我们像PC硬件产业那样最终聚焦到1~2种操作系统为核心的生态链上。而在SDN领域，目前尚无这样可以一统天下的控制器。Linux花了十年才成为服务器的主流操作系统之一，而OpenDayLight、ONOS尚为时过早，就更不要谈SDN早期那些偏学术实验性质的OpenFlow控制器了。网络面向的是企业/运营级市场，其订制化需求更多，对售后服务依赖更多，因此对于设备提供商的可持续发展能力要求甚高，因此SDN以及白牌交换机所许诺的完全开放网络的实现仍需假以时日。
开源社区的影响力
尽管早期业界就出现了大量的OpenFlow控制器，包括NOX、POX、FloodLight等，但是他们比较单薄的架构无法满足商用环境下多厂商互操作、高可用性的要求，因此在产业界的影响力较小。这一状况随着OpenDayLight开源项目的发布得到根本性的改观——目前已经有40多个厂商参与到OpenDayLight项目中。这使得ONF倍感威胁。2014年ONF加大了对开源社区的投入，其资助了几个开源社区项目，包括开源OpenFlow协议栈Libfluid;同时OpenFlow的发源地斯坦福大学也通过ONLab在12月份推出了ONOS开源SDN控制器。在已知的厂商中，博科完全采用了OpenDayLight作为其SDN解决方案的控制器，思科的非主流控制器XNC也是和OpenDayLight采用了相同的内核。
另外一方面，Open vSwitch从2.1.2版本开始基本支持了完整的OpenFlow标准，绝大部分基于OpenFlow 1.3的方案均可以通过OVS来进行组网或验证。尤其是基于SDN的Overlay方案，SDN控制器+OVS就可以搞定。Open vSwitch下一个2.4版本将加入对DPDK的支持，以进一步提升OVS转发性能，从而使得OVS在性能上接近目前商用的vSwitch，满足在更高流量场景下的应用。
在OpenStack领域，绝大部分SDN控制器均有了自己的Neutron Plug-In(插件)。同时对于业务链、L4~L7 层服务和SDN网络协同等议题及项目，也已经在OpenStack Juno版本及以后版本中支持，比如Group Based Policy项目在OpenStack Juno版本和OpenDayLight Helium版本就已经同步支持。
从SDN本身的产业链来讲(+微信关注网络世界)，控制器仍然位居核心地位，开源社区目前的影响力焦点也在与此。OpenDayLight在思科的控制下，毫无疑问和ONF有意无意地唱对台戏。从分裂SDN阵营的角度来看，其无疑已经成功了一半。OpenDayLight中支持了OpenFlow以外的不少南向接口，包括思科自己的OpFlex、LISP，以及OVSDB、BGP-LS、PCEP等接口。而对于ONF规范，目前尚不支持多OpenFlow版本同时运行，其对于OpenFlow多表转发模型的支持也流于形式，也无计划支持OF-Config。这使得要想在商用环境下部署ODL、使用OpenFlow接口，需要大量的开发工作。
当然，即使不使用OpenFlow，ODL离商用的距离也未必有显著差异。OpenDayLight的亮点在于模型驱动的开发方式以及SAL抽象层，但是其缺乏基本的网络模型、转发模型的公共抽象层，使得在其上开发的应用需要以烟囱形式开发。这对于应付单一的应用场景来说问题不大，但是对于希望构建一个通用的控制器平台来说，还有不小的距离。此外从代码质量上来讲，其和同样是Java为主的Android这样的单一厂商控制的开源项目相比差距较大。
2015年展望
SDN在数据中心中的应用已无悬念，业界已经基本准备好，无论是Overlay的架构，还是非Overlay的架构，2015年开始具备规模商用部署的能力。但是，这也仅仅是起点，SDN并没有走向如同网络产业东西向协议那样充分互操作的道路，而是如同IT业一样，采用了厂商联合的小集团方式构建一个完整的的解决方案。这其中OpenFlow和非OpenFlow方案都占据一席之地。笔者作为一个乐观派，仍然认为经过2~3年的博弈后，OpenFlow这样的标准协议仍然会成为南向协议的主流。
在运营商领域，NFV中应用SDN的步伐可能会紧跟数据中心应用之后。而在其他领域，主要场景包括IPRAN、PTN、WAN流量调度、OTN、EPC、vCPE等领域，SDN的集中管控理念将进一步贯彻，将出现更多的POC或试点。不过这肯定不是ONF定义的“控制器具有完全控制权”的SDN，而是会混合部分私有技术、部分传统技术以及可能的部分OpenFlow技术。即使如此，其商用化的进程也还尚未进入正轨，不仅厂商没有准备好，运营商更加没有准备好。这一过程，将持续3~5年的时间。或许更有可能的是，SDN在运营商网络退化或演进成一种高级网络管理架构，而非一种控制架构。
