从2009年业界首次提出SDN概念到现在已经是第六个年头；自2011年开放网络基金会（ONF，OpenNetworkingFoundation）成立以来，也是计算的第4个年头。与往年SDN的炒作相比，2014年无疑平淡了一些，但今年SDN的商用进程却在悄然加速。越来越多的厂商推出商用或试商用产品，越来越多的客户开始部署SDN或POC。测试。另一方面，开源社区在SDN商业化发展中的作用越来越显着：OpenDayLight（ODL）发布了helium版本，在集群和SAL架构上做了很大的改进；ONLab推出期待已久的ONOS开源SDN控制器，OpenvSwitch（OVS）也加速了对OpenFlow协议的支持，从2.3版本开始正式全面支持OpenFlow1.3和OpenFlow1.4的部分特性；越来越多的SDN解决方案用于云管理如OpenStack系统的底层网络实现。相比之下，SDNASIC芯片支持进展相对缓慢。因此，数据中心的主流解决方案仍然是基于overlay的解决方案，硬件交换机和控制器的多厂商互通解决方案距离商用还有很长的路要走。在非OpenFlowSDN领域，厂商的私有方案可能进展更快。Cisco的ACI解决方案和VMWare的NSX都赢得了一定的关注度。在电信运营商领域，2014年有很多基于SDN回传网络、光传输、CPE、流量优化的POC测试，但实际上大多是基于一些开放接口或对现有产品进行集中管控改造很大程度上，实验产品是现有技术的演进——包括基于边缘网络虚拟化、PCE技术甚至网络管理技术的演进。在运营商网络中，对稳定性、可靠性和性能的要求高于灵活性。提高了标准意义上引入SDN的门槛，降低了客户的价值。这使得运营商在基础网络中始终属于技术保守派。一个可比的例子是，2009年许多运营商开始对电信网元虚拟化进行评估和测试，而今天，NFV的普及才真正开启了运营商网络基础设施的虚拟化应用进程。SDN路由竞争SDN作为网络集中管控、接口开放的概念，在ONF的推动下得到了业界的认可。相反，由于CiscoACI解决方案和OpenDayLight开源项目的影响力越来越大，它变得越来越模糊。从OpenFlow的概念来看，它把所有的智能集中在一个集中的控制器中，转发平面只需要机械地执行转发指令，完全同构。这势必导致目前在网络行业占据主要市场份额的硬件设备市场进入门槛大幅降低，龙头厂商的地位因此受到威胁。他们从一开始就抵制SDN，然后拥抱SDN的概念，然后又力推一个与OpenFlow明显不同的解决方案。从厂商现有的SDN解决方案来看，南向接口大多支持OpenFlow1.0或1.3，但不少厂商也有自己的专有协议接口或现有IETF协议的变体，如ONEPK、OpFlex、BGP、XMPP、NetConf和私有RESTful接口。当然，出于营销的需要，他们基本上都会宣称是完全开放的接口，甚至在IETF中进行部分标准化的推动。这些解决方案与OpenFlow的根本区别在于转发平面仍然是一个自由网络，脱离中心化的控制器仍然可以运行基本的转发服务。差异化竞争力。ONF的架构文档特别指出SDN控制器必须完全控制转发平面，因此将此类解决方案归类为“伪SDN”。即使排除厂商的利益因素，从纯技术的角度来看，OpenFlow完全控制转发分离的架构对于协议体系的成熟和控制器产品的落地难度更大。如果没有逻辑上集中的控制器就无法运行的网络架构必然会带来额外的风险和成本。类似的场景是，在20世纪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的发源地斯坦福大学也在12月通过ONLab推出了ONOS开源SDN控制器。在已知厂商中，博科已全面采用OpenDayLight作为其SDN解决方案的控制器，而思科的非主流控制器XNC也采用与OpenDayLight相同的内核。另一方面，OpenvSwitch从2.1.2版本开始基本支持完整的OpenFlow标准，大部分基于OpenFlow1.3的解决方案都可以通过OVS进行组网或验证。尤其是基于SDN的Overlay方案，SDN控制器+OVS即可搞定。OpenvSwitch的下一个2.4版本将增加对DPDK的支持，进一步提升OVS的转发性能，使OVS的性能接近目前商用的vSwitch，满足更高流量场景的应用。在OpenStack领域，大部分SDN控制器都有自己的NeutronPlug-In（插件）。同时，业务链、L4~L7层服务、SDN网络协同等主题和项目在OpenStackJuno及之后的版本中也得到了支持。例如，GroupBasedPolicy项目已在OpenStackJuno和OpenDayLightHelium中同时得到支持。从SDN本身的产业链来看（+微信关注网络世界），控制器依然占据着核心地位，目前开源社区的影响力焦点也在这里。OpenDayLight在思科的控制之下，毫无疑问是有意无意地唱着ONF唱反调。从分裂SDN阵营的角度来看，无疑是成功了一半。OpenDayLight支持OpenFlow以外的很多南向接口，包括Cisco自己的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方案都占据一席之地。作为乐观主义者，笔者仍然认为经过两三年的博弈，OpenFlow等标准协议仍将成为南向协议的主流。在运营商领域，SDN在NFV中的应用步伐可能紧跟数据中心应用步伐。其他领域，主要场景包括IPRAN、PTN、WAN流量调度、OTN、EPC、vCPE等领域。SDN的集中管控理念将进一步落地，更多的POC或试点项目将会出现。不过，这肯定不是ONF定义的“控制器完全控制”的SDN，而是会混合一些专有技术，一些传统技术，可能还有一些OpenFlow技术。即便如此，其商业化进程仍未步入正轨。不仅制造商没有准备好，运营商也没有准备好。这个过程将持续3-5年。也许更有可能的是，SDN退化或演化为一种高级网络管理架构，而不是运营商网络中的控制架构。
