OpenFlow式革命与SDN成功之路

软件定义网络(SDN)有很多标准和组织，如OpenFlow、NFV和Open Daylight，后者由思科、IBM、微软、Big Switch、英特尔、Juniper等发起， Linux基金会合作支持，但似乎没有OpenFlow更为广为关注。

　　这也难怪，因为SDN始作俑者是OpenFlow。SDN诞生于2006年美国GENI资助的斯坦福大学Clean Slate课题，以斯坦福大学教授Nick McKeown为首的研究团队提出了Openflow概念，用来解决繁琐的网络设备配置工作，用软件的方式，对网络进行集中控制，此后，基于Openflow网络可编程特性，催生了SDN概念的诞生。

　　与大学科研需要相比，以Google为代表的.COM企业同样被网络设备的问题困扰。作为一种新兴的商业模式，互联网企业对效率以及成本的追逐近乎极致，现有网络设备更新换代周期长，管理和控制不够灵活，这都让编程能力非常强的互联网企业感觉到不便。

Facebook技术业务总监Najam Ahmad曾经指出：传统网络设备，就是一个黑盒子以及一些命令和协议接口，这就是你所购买的全部。更让人沮丧的是你会发现，一些网络设备只能由供应商拨号连接并通过秘密命令到ASIC(专用集成电路 )来解决问题，而这并没有通过CLI(命令行接口界面)提供给用户。

　　“我们不想这样来管理网络环境，我们希望直接写硬件” Ahmad说。

　　为了直接写硬件，Google采取的方法是找网络OEM厂商直接定制设备。对于Google来说，既让服务器可以定制，网络设备定制自然不在话下。与服务器定制相比，网络设备定制更加简单。按照Openflow的思路，网络设备主要是连接，有关交换、路由的控制由上层的软件来完成，也就是说，Openflow的交换机纯属一种傻瓜式的交换机，对于OEM厂商来说，这样的设备是小菜一碟。

　　Google也好，Faceboo可也好，规模化的优势，可以让他们的SDN梦想成为现实。与之相比，传统的行业/企业用户则没有Google、Facebook和大学、科研机构洒脱，一来其技术实力和人才队伍相对有限，二来往往会有一些历史的包袱，常常要考虑旧有系统的兼容性，即使行业/企业希望推到重来，他们还是需要依赖第三方专业化的服务，为他们提供网络服务的，主要是思科、Juniper等网络厂商。

　　对于网络厂商而言，“傻瓜式”Openfolw交换机无疑淡化了其地位和作用，没有技术含量的“傻瓜式”交换机是赚不到钱的，网络厂商怎么会甘心做这样的傻事。对于网络厂商而言，支持Opneflow是为了吃着碗里盯着锅里，是为了多分一杯羹。这有点类似存储虚拟化，都希望别人的阵列只是单纯的磁盘，而自己作为管理控制的核心。

　　网络厂商是不会轻易交出控制权的，另外也不是所有的用户都像Google、Facebook、斯坦福大学一样，自己具有软件定义能力。所以，网络厂商会顺应SDN的趋势，这也是Open Daylight应运而生的原因。

　　不同于Openflow，网络厂商Open Daylight不是一种革命式的变革，而是在现有网络的基础上，透过叠加网(Overlay)实现SDN的诉求。它不是推倒从来，因此更容易得到广泛支持。目前思科、博科，以及VMware都推出了基于Overlay的SDN解决方案。

　　Overlay没有Openflow理想和彻底，但如果理想脱离了现实，难免也会曲高和寡。与Openflow相比，Overlay更接地气，也具有更好的继承性。对于行业/企业用户来说，也可以更好延续与合作厂商长期以来建立的合作关系。

　　Openflow虽好，但需要自己动手，需要自己有一定的能力，另外，Openflow很难兼容现有网络基础。与之相比，Overlay相对风险要小很多，在保持现状同时，更加具有灵活性，可选择的余地比较大。

　　对于SDN来说，服务器 虚拟化是另一大动因。服务器虚拟化应用，导致网络东西流量( 数据中心服务器设备之间)大增，而传统网络设备应对这些东西流量效率不高，SDN也是为了很好解决这些问题。可以预见，服务器虚拟化日益普及，其矛盾会更加突出，届时对SDN的需求会更加普遍。从产品角度来看，网络硬件设备受限于生命周期，将很难满足业务灵活发展的需要，只有软件定义才能够满足灵活性的需要，因此，SDN将会大行其道