“柔性”网络为云应用而来

OpenFlow控制器可以拥有有全网视图，可以动态防止环路发生。OpenFlow不但增加了传统转发平面的效率，在提供高级网络服务方面还可以展现独特价值，比如多对一网络虚拟化、分布式负载均衡和分布式防火墙或入侵检测。每一类分布式网络资源服务与每个云租户对应，每个云租户都有独立的虚拟网络架构，把硬件细节隐藏起来了，比如不同数目地理位置无关的虚拟端口交换机。在产品化方面，NEC公司第一个推出了OpenFlow交换机PF5240，带有48个千兆和4个万兆上联端口，还开发了OpenFlow控制软件支持OpenFlow兼容交换机。

软件定义网络商业应用展望

软件定义网络OpenFlow在超大规模Web 2.0数据中心网络应用展望

Web 2.0用户如Google、Facebook的服务器台数近百万台，单个数据中心服务器的数目也超过十万台，国内公司如腾讯、阿里巴巴和百度安装的总服务器数估计也超过数十万台。为了进一步降低IT总成本，整合与开源虚拟化是下一代Web 2.0架构的发展趋势，单一数据中心虚拟机数目将部署到上十万台，这种环境下的公有云的虚拟化、移动性比我们之前说的私有云移动性来得技术更加复杂、管理更加困难，传统网络厂家的设备很难满足超大规模的"信息流"要求。

同时我们看到，从传统网络架构迁移到软件定义网络将是一个艰难的旅程。网络技术应用演变过程不外乎有两种方式，一种是先边缘后核心，另外一种是先中心后边缘。不过从客户体验来看，先边缘后核心是更容易接受的应用方式，所以我们可以预计OpenFlow应用也将是从边缘到核心的过程。

具体方式比如是用户在接入层采用OpenFlow交换机，建立独立控制网，安装独立开发的或商用的OpenFlow控制软件，从系统和网络管理采集数据流量模式和优化定义规则。

图4 OpenFlow基于3层网络建立2层虚拟化转发路径

如上图所示，OpenFlow在大规模虚拟化数据中心的应用。OpenFlow在数据中心网络里建立从一台虚拟机到另外一台虚拟机的转发路径，基于三层网络基础上建立了二层以太网交换网络。OpenFlow扩展了三层相对静态功能，根据数据流动态建立负载均衡决策路径，并依据虚拟化交换网络配置改变最优化的转发路径，从而简化了大型数据中心3层网络适应2层虚拟机移动性要求。戴尔公司已联合微软公司向IETF提交了NVGRE RFC，实现基于3层2层虚拟化通道协议，将有助于更快推动OpenFlow在大规模云计算网络中普及应用。

软件定义网络OpenFlow在电信运营商网络应用展望

在传统电信运营商网络里，IP网络和传输网络是独立分离的，它们分别单独管理，IP网和传输网之间没有交互，IP链路静态配置，传输层电路或放大器也是静态的，导致不同层次功能和资源重复，增加了用户采购成本和运营成本负担。

在云计算环境下，运营商需要跨越数据中心进行资源管理，实现上层资源与物理链路层调度的匹配与自动化以更好复用资源，满足每个云租户在数据中心之外需要建立端到端虚拟网络自动服务。那什么才是运营商网络的最佳控制和管理方式呢?可不可以基于"信息流"的报文交换与电路交换融合的联合控制方式呢?答案是完全可能的。如图5所示，解决思路是按光纤、放大器、时隙和报文内容等细分，从不同网络需求抽象映射到OSI 1到4层"信息流"，每个网络节点通过OpenFlow实现提供网络虚拟化服务。斯坦福大学的有关专家正在积极研究这样的融合项目，基于不同流量和应用模型建立端对端网络虚拟化，这些研究为OpenFlow在运营商网络的应用提供了无限的可能性。

图5 运营商基于"流"统一控制管理网络服务

软件定义网络的发展挑战

尽管软件定义网络发展可以帮助我们解决云计算网络的管理和经济问题，前途是非常光明的，但从目前发展阶段来看还是需要较长时间的发展和普及过程，从技术本身到管理和市场方面都有不少的挑战。

第一点，从纯技术观点看，OpenFlow控制性能问题。OpenFlow按"信息流"控制网络，以致每个控制节点和转发节点需要维护大量端对端"信息流"表，控制节点或转发节点的内存及其他资源需要相应提高。大规模突发首次"信息流"建立可能会导致新的"信息流"瓶颈问题。而且如果控制点出现故障，大量"信息流"需要在转发节点重建，突发"信息流"配置对网络性能和鲁棒性都会有潜在的巨大影响。

第二点，从厂商观点看，是OpenFlow的应用成熟度问题。目前OpenFlow还只应用于科学实验和校园内部网，没有大规模产品化转发节点，一方面是没有在大规模客户安装基础之上的产品质量保证，另一方面是量产之前的成本优势还有很大疑问。除了转发节点成熟度问题外，因为目前并没有商业化的控制平台，如何实现控制