OpenFlow
浏览次数：488次  最近更新：2015-11-25 19:10:51

概述

OpenFlow论坛起源于斯坦福大学一个名为“Clean Slate”的以重新设计互联网为目标的计划，创立于2008年。该论坛最早的成员只有斯坦福大学的高性能网络研究组(The High Performance Networking Group)。随着论坛的发展，OpenFlow论坛已经变成一个由大学研究者和网络管理者共同组成的开放论坛，吸引了来自麻省理工学院、加州理工学院等著名高校的教授以及德国电信等许多大型运营商的一线创立于2008年，工程师加盟。为防止制造商的利益冲突被引入论坛，OpenFlow论坛不欢迎来自网络设备制造商的人员加入。

OpenFlow论坛主要解决的是重新设计互联网的实验环境问题。在纯的实验网上总难以有足够多的实际用户或者足够大的网络拓扑来测试新协议的性能和功能，最好的方法是将运行新协议的实验网络嵌入实际运营的网络，利用实际的网络环境来检验新协议的可行性和存在的问题。

传统的解决方案有两种，要求设备制造商完全开放平台接口或实验者自行制造设备。设备制造商完全开放平台接口让研究者可以使用商用网络设备进行二次开发，寻找实验协议与传统协议并存的方法。但是，直接开放网络设备的开发接口对设备提供商而言是一场噩梦，一方面与商用平台的封闭性相冲突，开放开发的二次接口无疑会有暴露自身技术细节的风险，为竞争对手提供了机会，或者为新兴厂家提供了进入行业的门槛。

OpenFlow的特点

开发者自行制造设备的方法一般是使用PC服务器或专用硬件搭建自己的交换路由设备，受限于主机能装备的网卡数量， 这种方法不能获得足够大密度的端口(一般交换机很容易达到48或者更多的端口，而主机即使插上多块网卡也很难有这么多的端口)，而且研究设备的交换性能一般也远不如同价格的商用设备。在这种情况下，OpenFlow论坛提出新的交换设备解决方案必须具有以下四点性质：
第一，设备必须具有商用设备的高性能和低价格的特点；
第二，设备必须能支持各种不同的研究范围；
第三，设备必须能隔绝实验流量和运行流量；
第四，设备必须满足设备制造商封闭平台的要求。

仿效计算机领域软硬件分离的做法，OpenFlow交换机将原来完全由交换机/路由器控制的报文转发过程转化为由OpenFlow交换机（OpenFlow Switch）和控制服务器（Controller）来共同完成，从而实现了数据转发和路由控制的分离。控制器可以通过事先规定好的接口操作来控制OpenFlow交换机中的流表，从而达到控制数据转发的目的。

OpenFlow网络由OpenFlow交换机、FlowVisor（网络虚拟化层）和Controller（控制器）三部分组成。OpenFlow交换机进行数据层的转发；FlowVisor对网络进行虚拟化；Controller对网络进行集中控制，实现控制层的功能。

OpenFlow交换机

OpenFlow交换机是整个OpenFlow网络的核心部件，主要管理数据层的转发。OpenFlowSwitch拥有一个FlowTable（流表），它只按照流表进行转发，FlowTable的生成、维护和下发由外置的Controller来实现。这里的FlowTable并非是指IP五元组（IP源地址、IP目的地址、协议号、源端口、目的端口），OpenFlow1.0规范定义了包括输入端口、MAC源地址、MAC目的地址、以太网类型、VLANID、IP源地址、IP目的地址、IP端口、TCP源端口、TCP目的端口在内的10个关键字（十元组）。FlowTable中的每个关键字都可以通配，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么FlowTable中就可以只有IP目的地址字段是有效的，其它全为通配。传统网络中数据包的流向是人为指定的，虽然交换机、路由器拥有控制权，却没有数据流的概念，只进行数据包级别的交换；而在OpenFlow网络中，统一的Controller取代路由，决定了所有数据包在网络中传输路径。

OpenFlow采用控制和转发分离的架构，意味着MAC地址的学习由Controller来实现，VLAN和基本的路由配置也由Controller下发给OpenFlowSwitch。对于三层网络设备，各类路由器运行在Controller之上，Controller根据需要下发给相应的路由器。当一个Controller同时控制多个OpenFlowSwitch时，它们看起来就像一个大的逻辑交换机。FlowTable的下发可以是主动的，也可以是被动的。

主动模式：Controller将自己收集的FlowTable信息主动下发给OpenFlowSwitch，随后OpenFlowSwitch可以直接根据FlowTable进行转发。

被动模式：OpenFlowSwitch收到数据包后，首先在本地的FlowTable上查找转发目标端口，如果没有匹配，则把数据包转发给Controller，由控制层决定转发端口，并下发相应的FlowTable。被动模式的好处是网络设备无需维护全部的FlowTable，只有当实际的流量产生时才向Controller获取FlowTable记录并存储，当记录老化时可以删除相应的FlowTable，故可以大大节省存储器空间。

FlowVisor

类比计算机的虚拟化，FlowVisor就是位于硬件结构元件和软件之间的网络虚拟层。FlowVisor允许多个控制器同时控制一台OpenFlow交换机，但是每个控制器仅仅可以控制经过这个OpenFlow交换机的某一个虚拟网络（即slice）。因此通过FlowVisor建立的试验平台可以在不影响商业流的转发速度的情况下，允许多个网络试验在不同的虚拟网络上同时进行。FlowVisor与一般的商用交换机是兼容的，而不需要使用FPGA和网络处理器等可编程硬件。

Controller

Controller通过OpenFlow协议这个标准接口对OpenFlow交换机中的流表进行控制，从而实现对整个网络进行集中控制。Controller的这一切功能都要通过运行NOX来实现，因此NOX就像是OpenFlow网络的操作系统。此外，在NOX上还可以运行Plug-n-serve、OpenRoads以及OpenPipes等应用程序。

OpenFlow的发展

2008年以来，OpenFlow论坛已经在硬件和软件支持方面取得了长足的发展。包括思科，Juniper,NEC,华为等许多公司推出了支持OpenFlow的交换机、路由器、无线网络接入点（AP）等网络设备。此外，具有OpenFlow功能的AP也已在斯坦福大学进行了部署，标志着OpenFlow已不再局限于固网。2009年12月，OpenFlow规范发布了具有里程碑意义的可用于商业化产品的1.0版本，而且支持规范1.0的软件indigo也已发布了Beta版本。OpenFlow已经在美国斯坦福大学、Internet2、日本的JGN2plus以及其他的10-15个科研机构中部署，并将在国家科研骨干网以及其他科研和生产中应用。OpenFlow的国际覆盖已经包括日本、葡萄牙、意大利、西班牙、波兰和瑞典等。

2015年11月24日，华为宣布其交换机符合OpenFlow V1.3标准

OpenFlow与SDN

OpenFlow作为SDN底层实现的一个理想选择，在转发层面确实有很多优势，但是也有很多需要注意的点[1]：将控制平面和转发平面进行分离，减少了控制点，增加了控制平面的负担，需要比以往有更强的CPU计算能力的设备才能堪重负；    SDN强调管理员在管理网络方面的能力，这些无疑对管理员的技能和对所管理的业务熟悉度有了更高一步的要求，这点与网络设备智能化、自动化、傻瓜化的发展思想多少是有点相悖的；
    OpenFlow的多表项为业务实现提供了灵活性，但是这无疑增加了设备的成本，并且为交换芯片驱动开发人员在软件中记录和维护配置表项、容错等研发工作提供相当大的复杂度；
    OpenFlow在转发层面相比于传统方式有了很大提高，应该是先兼容以前所有的转发方式，但是现在的标准中，还有很多传统转发方式支持但是OpenFlow中不支持的，比如我要实现某个出端口中SIP=1.1.1.1的报文全丢弃，标准中暂时没有出现匹配出端口的的内容，希望OpenFlow标准尽快得到完善；
    传统交换机中还有很多非产生直接转发意义或动作方面的功能，比如流控、队列调度、WRED等方面都要涉及交换芯片MMU，而这些OpenFlow是很难对各个厂家通过标准而统一的，所以OpenFlow标准化方面还有很多的工作要做；

参考文献

关于OpenFlow的更多信息，可以参考网址 https://www.opennetworking.org/
关于OpenFlow的历史信息可以参考：archive.openflow.org.
[1]http://www.csdn.net/article/2014-03-14/2818768-SDN-OpenFlow