云计算的发展，是以虚拟化技术为基础的。云计算服务商以按需分配为原则，为客户提供具有高可用性、高扩展性的计算、存储和网络等IT资源。虚拟化技术将各种物理资源抽象为逻辑上的资源，隐藏了各种物理上的限制，为在更细粒度上对其进行管理和应用提供了可能性。
近些年，计算的虚拟化技术(主要指x86平台的虚拟化)取得了长足的发展;相比较而言，尽管存储和网络的虚拟化也得到了诸多发展，但是还有很多问题亟需解决，在云计算环境中尤其如此。
OpenFlow和SDN尽管不是专门为网络虚拟化而生，但是它们带来的标准化和灵活性却给网络虚拟化的发展带来无限可能。希望通过本文对OpenFlow/SDN做一个初步介绍，以期帮助大家能够进一步深入了解和学习OpenFlow/SDN，欢迎批评和指正。
起源与发展
OpenFlow起源于斯坦福大学的Clean Slate项目组 。CleanSlate项目的最终目的是要重新发明英特网，旨在改变设计已略显不合时宜，且难以进化发展的现有网络基础架构。在2006年，斯坦福的学生 Martin Casado领导了一个关于网络安全与管理的项目Ethane，该项目试图通过一个集中式的控制器，让网络管理员可以方便地定义基于网络流的安全控制策略，并将这些安全策略应用到各种网络设备中，从而实现对整个网络通讯的安全控制。
受此项目(及Ethane的前续项目Sane)启发，Martin和他的导师Nick McKeown教授(时任Clean Slate项目的Faculty Director)发现，如果将Ethane的设计更一般化，将传统网络设备的数据转发(data plane)和路由控制(control plane)两个功能模块相分离，通过集中式的控制器(Controller)以标准化的接口对各种网络设备进行管理和配置，那么这将为网络资源的设计、管理和使用提供更多的可能性，从而更容易推动网络的革新与发展。
于是，他们便提出了OpenFlow的概念，并且Nick McKeown等人于2008年在ACM SIGCOMM发表了题为OpenFlow: Enabling Innovation in Campus Networks的论文，首次详细地介绍了OpenFlow的概念。该篇论文除了阐述OpenFlow的工作原理外，还列举了OpenFlow几大应用场景，包括：
1)校园网络中对实验性通讯协议的支持(如其标题所示);
2) 网络管理和访问控制;
3)网络隔离和VLAN;
4)基于WiFi的移动网络;
5)非IP网络;
6)基于网络包的处理。当然，目前关于OpenFlow的研究已经远远超出了这些领域。
基于OpenFlow为网络带来的可编程的特性，Nick和他的团队(包括加州大学伯克利分校的Scott Shenker教授)进一步提出了SDN(Software Defined Network, 目前国内多直译为“软件定义网络”)的概念--其实，SDN的概念据说最早是由KateGreene于2009年在TechnologyReview网站上评选年度十大前沿技术时提出。
如果将网络中所有的网络设备视为被管理的资源，那么参考操作系统的原理，可以抽象出一个网络操作系统(Network OS)的概念—这个网络操作系统一方面抽象了底层网络设备的具体细节，同时还为上层应用提供了统一的管理视图和编程接口。这样，基于网络操作系统这个平台，用户可以开发各种应用程序，通过软件来定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无需关心底层网络的物理拓扑结构。关于SDN的概念和原理，可以参考开放网络基金会(Open NetworkingFoundation)于今年4月份发表的SDN白皮书Software Defined Networking：The New Norm forNetworks 。
从上面的描述中，可以看出OpenFlow/SDN的原理其实并不复杂，从严格意义上讲也很难算是具有革命性的创新。然而OpenFlow /SDN却引来了业界越来越多的关注，成为近年来名副其实的热门技术。目前，包括HP、IBM、Cisco、NEC以及国内的华为和中兴等传统网络设备制造商都已纷纷加入到OpenFlow的阵营，同时有一些支持OpenFlow的网络硬件设备已经面世。
2011年，开放网络基金会(Open Networking Foundation)在Nick等人的推动下成立，专门负责OpenFlow标准和规范的维护和发展;同年，第一届开放网络峰会 (OpenNetworking Summit)召开，为OpenFlow和SDN在学术界和工业界都做了很好的介绍和推广。
第二届峰会上，来自Google的Urs H lzle在以OpenFlow@Google为题的Keynote演讲中宣布Google已经在其全球各地的数据中心骨干网络中大规模地使用 OpenFlow/SDN，从而证明了OpenFlow不再仅仅是停留在学术界的一个研究模型，而是已经完全具备了可以在产品环境中应用的技术成熟度。最近，Facebook也宣布其数据中心中使用了OpenFlow/SDN的技术。
OpenFlow标准和规范
自2010年初发布第一个版本(v1.0)以来，OpenFlow规范已经经历了1.1、1.2以及最近刚发布的1.3等版本。同时，今年年初 OpenFlow管理和配置协议也发布了第一个版本(OF-CONFIG 1.0 & 1.1)。下图列出了OF和OF-CONFIG规范各个版本的发展历程及变化，从图中可以看到目前使用和支持最多的仍然是1.0和1.1版本。
在这里，我们将详细介绍一下OpenFlow Switch的最新规范(即OF-1.3)。下图选自Nick等人的论文OpenFlow：EnablingInnovation in Campus Networks 。这张图常被用来说明OpenFlow的原理和基本架构。其实，这张图还很好地表明了OpenFlow Switch规范所定义的范围—从图上可以看出，OpenFlow Switch规范主要定义了Switch的功能模块以及其与Controller之间的通信信道等方面。
#p#
OF规范主要分为如下四大部分，
1. OpenFlow的端口(Port)
OpenFlow规范将Switch上的端口分为3种类别：
a) 物理端口，即设备上物理可见的端口;
b) 逻辑端口，在物理端口基础上由Switch设备抽象出来的逻辑端口，如为tunnel或者聚合等功能而实现的逻辑端口;
c) OpenFlow定义的端口。OpenFlow目前总共定义了ALL、CONTROLLER、TABLE、IN_PORT、ANY、LOCAL、 NORMAL和FLOOD等8种端口，其中后3种为非必需的端口，只在混合型的OpenFlow Switch(OpenFlow-hybrid Switch，即同时支持传统网络协议栈和OpenFlow协议的Switch设备，相对于OpenFlow-only Switch而言)中存在。
2. OpenFlow的FlowTable(国内有直译为“流表”的)
OpenFlow通过用户定义的或者预设的规则来匹配和处理网络包。一条OpenFlow的规则由匹配域(Match Fields)、优先级(Priority)、处理指令(Instructions)和统计数据(如Counters)等字段组成，如下图所示。
在一条规则中，可以根据网络包在L2、L3或者L4等网络报文头的任意字段进行匹配，比如以太网帧的源MAC地址，IP包的协议类型和IP地址，或者TCP/UDP的端口号等。目前OpenFlow的规范中还规定了Switch设备厂商可以选择性地支持通配符进行匹配。据说，OpenFlow在未来还计划支持对整个数据包的任意字段进行匹配。
所有OpenFlow的规则都被组织在不同的FlowTable中，在同一个FlowTable中按规则的优先级进行先后匹配。一个 OpenFlow的Switch可以包含一个或者多个FlowTable，从0依次编号排列。OpenFlow规范中定义了流水线式的处理流程，如下图所示。当数据包进入Switch后，必须从FlowTable 0开始依次匹配;
FlowTable可以按次序从小到大越级跳转，但不能从某一FlowTable向前跳转至编号更小的FlowTable。当数据包成功匹配一条规则后，将首先更新该规则对应的统计数据(如成功匹配数据包总数目和总字节数等)，然后根据规则中的指令进行相应操作--比如跳转至后续某一 FlowTable继续处理，修改或者立即执行该数据包对应的Action Set等。
当数据包已经处于最后一个FlowTable时，其对应的Action Set中的所有Action将被执行，包括转发至某一端口，修改数据包某一字段，丢弃数据包等。OpenFlow规范中对目前所支持的 Instructions和Actions进行了完整详细的说明和定义。
另外，OpenFlow规范中还定义了很多其他功能和行为，比如OpenFlow对于QoS的支持(即MeterTable和Meter Bands的定义等)，对于GroupTable的定义，以及规则的超时处理等。
OpenFlow的通信通道
这一节中，OpenFlow规范定义了一个OpenFlow Switch如何与Controller建立连接、通讯以及相关消息类型等。
OpenFlow规范中定义了三种消息类型：
a) Controller/Switch消息，是指由Controller发起、Switch接收并处理的消息，主要包括Features、 Configuration、Modify-State、Read-State、Packet-out、Barrier和Role-Request等消息。这些消息主要由Controller用来对Switch进行状态查询和修改配置等操作。
b) 异步(Asynchronous)消息，是由Switch发送给Controller、用来通知Switch上发生的某些异步事件的消息，主要包括 Packet-in、Flow-Removed、Port-status和Error等。例如，当某一条规则因为超时而被删除时，Switch将自动发送一条Flow-Removed消息通知Controller，以方便Controller作出相应的操作，如重新设置相关规则等。
c) 对称(Symmetric)消息，顾名思义，这些都是双向对称的消息，主要用来建立连接、检测对方是否在线等，包括Hello、Echo和Experimenter三种消息。
下图展示了OpenFlow和Switch之间一次典型的消息交换过程，出于安全和高可用性等方面的考虑，OpenFlow的规范还规定了如何为Controller和Switch之间的信道加密、如何建立多连接等(主连接和辅助连接)。
#p#
OpenFlow协议及相关数据结构
在OpenFlow规范的最后一部分，主要详细定义了各种OpenFlow消息的数据结构，包括OpenFlow消息的消息头等。这里就不一一赘述，如需了解可以参考OpenFlow源代码中openflow.h头文件中关于各种数据结构的定义。
OpenFlow的应用
随着OpenFlow/SDN概念的发展和推广，其研究和应用领域也得到了不断拓展。目前，关于OpenFlow/SDN的研究领域主要包括网络虚拟化、安全和访问控制、负载均衡、聚合网络和绿色节能等方面。另外，还有关于OpenFlow和传统网络设备交互和整合等方面的研究。
下面将举几个典型的研究案例来展示OpenFlow的应用。
1. 网络虚拟化 – FlowVisor
网络虚拟化的本质是要能够抽象底层网络的物理拓扑，能够在逻辑上对网络资源进行分片或者整合，从而满足各种应用对于网络的不同需求。为了达到网络分片的目的，FlowVisor实现了一种特殊的OpenFlow Controller，可以看作其他不同用户或应用的Controllers与网络设备之间的一层代理。
因此，不同用户或应用可以使用自己的Controllers来定义不同的网络拓扑，同时FlowVisor又可以保证这些Controllers之间能够互相隔离而互不影响。
下图展示了使用FlowVisor可以在同一个物理网络上定义出不同的逻辑拓扑。FlowVisor不仅是一个典型的OpenFlow应用案例，同时还是一个很好的研究平台，目前已经有很多研究和应用都是基于FlowVisor做的。
2. 负载均衡 – Aster*x
传统的负载均衡方案一般需要在服务器集群的入口处，通过一个gateway或者router来监测、统计服务器工作负载，并据此动态分配用户请求到负载相对较轻的服务器上。既然网络中所有的网络设备都可以通过OpenFlow进行集中式的控制和管理，同时应用服务器的负载可以及时地反馈到 OpenFlowController那里，那么OpenFlow就非常适合做负载均衡的工作。
Aster*x通过Host Manager和Net Manager来分别监测服务器和网络的工作负载，然后将这些信息反馈给FlowManager，这样Flow Manager就可以根据这些实时的负载信息，重新定义网络设备上的OpenFlow规则，从而将用户请求(即网络包)按照服务器的能力进行调整和分发。
3. 绿色节能的网络服务 – ElasticTree
在数据中心和云计算环境中，如何降低运营成本是一个重要的研究课题。能够根据工作负荷按需分配、动态规划资源，不仅可以提高资源的利用率，还可以达到节能环保的目的。
ElasticTree创新性地使用OpenFlow，在不影响性能的前提下，根据网络负载动态规划路由，从而可以在网络负载不高的情况下选择性地关闭或者挂起部分网络设备，使其进入节电模式达到节能环保、降低运营成本的目的。
结语
没有任何一项技术可以解决所有问题，我们相信OpenFlow/SDN也不会是解决现有所有网络问题的“万金油”。但是，我们相信 OpenFlow/SDN的确给网络变革和创新带了许多机遇—既然网络问题已经变得可以通过编程来解决的时候，技术宅们该出手了，拯救网络世界的时候到了!
