OpenFlow相关的历史、新闻：http://blog.csdn.net/jincm13/article/details/7825754
起源与发展【https://36kr.com/p/5035985】
OpenFlow起源于斯坦福大学的Clean Slate项目组 [1] 。CleanSlate项目的最终目的是要重新发明英特网，旨在改变设计已略显不合时宜，且难以进化发展的现有网络基础架构。在2006年，斯坦福的学生Martin Casado领导了一个关于网络安全与管理的项目Ethane[2]，该项目试图通过一个集中式的控制器，让网络管理员可以方便地定义基于网络流的安全控制策略，并将这些安全策略应用到各种网络设备中，从而实现对整个网络通讯的安全控制。受此项目（及Ethane的前续项目Sane[3]）启发，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[4]的论文，首次详细地介绍了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网站上评选年度十大前沿技术时提出[5]。如果将网络中所有的网络设备视为被管理的资源，那么参考操作系统的原理，可以抽象出一个网络操作系统（Network OS）的概念—这个网络操作系统一方面抽象了底层网络设备的具体细节，同时还为上层应用提供了统一的管理视图和编程接口。这样，基于网络操作系统这个平台，用户可以开发各种应用程序，通过软件来定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无需关心底层网络的物理拓扑结构。关于SDN的概念和原理，可以参考开放网络基金会（Open NetworkingFoundation）于2012年4月份发表的SDN白皮书Software Defined Networking：The New Norm forNetworks [6] 。
从上面的描述中，可以看出OpenFlow/SDN的原理其实并不复杂，从严格意义上讲也很难算是具有革命性的创新。然而OpenFlow/SDN却引来了业界越来越多的关注，成为近年来名副其实的热门技术。目前，包括HP、IBM、Cisco、NEC以及国内的华为和中兴等传统网络设备制造商都已纷纷加入到OpenFlow的阵营，同时有一些支持OpenFlow的网络硬件设备已经面世。2011年，开放网络基金会（Open Networking Foundation）在Nick等人的推动下成立，专门负责OpenFlow标准和规范的维护和发展；同年，第一届开放网络峰会（OpenNetworking Summit）召开，为OpenFlow和SDN在学术界和工业界都做了很好的介绍和推广。2012年初召开的第二届峰会上，来自Google的Urs Hölzle在以[email protected][7]为题的Keynote演讲中宣布Google已经在其全球各地的数据中心骨干网络中大规模地使用OpenFlow/SDN，从而证明了OpenFlow不再仅仅是停留在学术界的一个研究模型，而是已经完全具备了可以在产品环境中应用的技术成熟度。最近，Facebook也宣布其数据中心中使用了OpenFlow/SDN的技术。
自2010年初发布第一个版本（v1.0）以来，OpenFlow规范已经经历了1.1、1.2以及最近刚发布的1.3等版本。同时，今年(2012)年初OpenFlow管理和配置协议也发布了第一个版本(OF-CONFIG 1.0 & 1.1)
在这里，我们将详细介绍一下OpenFlow Switch的最新规范(即OF-1.3)。下图选自Nick等人的论文OpenFlow：EnablingInnovation in Campus Networks 。这张图常被用来说明OpenFlow的原理和基本架构。其实，这张图还很好地表明了OpenFlow Switch规范所定义的范围—从图上可以看出，OpenFlow Switch规范主要定义了Switch的功能模块以及其与Controller之间的通信信道等方面。
在进行OpenFlow原理说明前，先了解一些基本情况:
OpenFlow规范是什么？
OpenFlow是一套软件API，它允许一个“控制器”将配置信息发送给交换机。这个配置往往指的是一个“流”及其附属的某些“操作”。
“流”是一组定义的帧或者数据包（类似于一个MPLS流）与一组操作。例如：
Source IP/Port、Destination IP/Port和Drop。
Source IP、Destination IP和QoS Action。
Source MAC、Destination MAC和L2 Path。
通过OpenFlow，您可以将一组规则发送给一台“配置”设备的交换机或者路由器。然后每个设备会根据它的类型使用这些数据。交换机会更新它的MAC地址表以转发帧，路由器会添加访问列表，而防火墙会更新它的规则。
软件定义网络是什么？
当组织将网络配置从设备迁移到软件平台时，交换机就变得更加简单和廉价了。但是主要的受益是网络配置可以由中央控制器管理。
控制者是一个包含算法、数学、分析和规则的软件，它来自规则组，并使用OpenFlow将配置下载到网络设备中。因此，当控制器评估和重新平衡配置时，网络就可能动态地进行重新配置。这就是所谓的软件定义网络。
SDN（Software Defined Network）：
它是基于OpenFlow实现的。在SDN中，交换设备的数据转发层和控制层是分离的，因此网络协议和交换策略的升级只需要改动控制层。OpenFlow在OpenFlow交换机上实现数据转发，而在控制器上实现数据的转发控制，从而实现了数据转发层和控制层的分离。基于OpenFlow实现SDN，则在网络中实现了软硬件的分离以及底层硬件的虚拟化，从而为网络的发展提供了一个良好的发展平台。
OpenFlow网络由OpenFlow交换机、FlowVisor和Controller三部分组成。
OpenFlow交换机进行数据层的转发；
FlowVisor对网络进行虚拟化；
Controller对网络进行集中控制，实现控制层的功能。
OpenFlow交换机是整个OpenFlow网络的核心部件，主要管理数据层的转发。OpenFlow交换机接收到数据包后，首先在本地的流表上查找转发目标端口，如果没有匹配，则把数据包转发给Controller，由控制层决定转发端口。
Controller
OpenFlow实现了数据层和控制层的分离，其中OpenFlow交换机进行数据层的转发，而Controller实现了控制层的功能。Controller通过OpenFlow协议这个标准接口对OpenFlow交换机中的流表进行控制，从而实现对整个网络进行集中控制。Controller的这一切功能都要通过运行NOX来实现，因此NOX就像是OpenFlow网络的操作系统。此外，在NOX上还可以运行Plug-n-serve、OpenRoads以及OpenPipes等应用程序。
Plug-n-Serve 通过规定数据传输路径来控制网络以及服务器上的负载，从而使得负载均衡并降低响应时间。
OpenRoads 是支持OpenFlow无线网络移动性研究的框架。
OpenPipes 可以在网络系统中通过移动每个子模块来测试每个子模块，并可以决定如何划分设计单元。
OpenFlow交换机的组成
OpenFlow交换机由流表、安全通道和OpenFlow协议三部分组成。
安全通道是连接OpenFlow交换机到控制器的接口。控制器通过这个接口控制和管理交换机，同时控制器接收来自交换机的事件并向交换机发送数据包。交换机和控制器通过安全通道进行通信，而且所有的信息必须按照OpenFlow协议规定的格式来执行。
OpenFlow协议用来描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。协议的核心部分是用于OpenFlow协议信息结构的集合。
OpenFlow协议支持三种信息类型：Controller-to-Switch，Asynchronous和Symmetric，每一个类型都有多个子类型。
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的规范还规定了如何为Controller和Switch之间的信道加密、如何建立多连接等(主连接和辅助连接)。
OpenFlow交换机的分类
按照对OpenFlow的支持程度，OpenFlow交换机可以分为两类：
专用的OpenFlow交换机：
它是专门为支持OpenFlow而设计的。它不支持现有的商用交换机上的正常处理流程，所有经过该交换机的数据都按照OpenFlow的模式进行转发。专用的OpenFlow交换机中不再具有控制逻辑，因此专用的OpenFlow交换机是用来在端口间转发数据包的一个简单的路径部件。
支持OpenFlow的交换机：
它是在商业交换机的基础上添加流表、安全通道和OpenFlow协议来获得了OpenFlow特性的交换机。其既具有常用的商业交换机的转发模块，又具有OpenFlow的转发逻辑，因此支持OpenFlow的交换机可以采用两种不同的方式处理接收到的数据包。
按照OpenFlow交换机的发展程度来分，OpenFlow交换机也可以分为两类：
“Type0”交换机：
它仅仅支持十元组以及以下四个操作：
1. 转发这个流的数据包给一个给定的端口（或者几个端口）；
2. 压缩并转发这个流的数据包给控制器；
3. 丢弃这个流的数据包；
4. 通过交换机的正常处理流程来转发这个流的数据包。
“Type1”交换机：
由于“Type0”交换机的这些功能是不能满足复杂试验要求的，因此就定义“Type1”交换机来支持更多的功能，从而支持复杂的网络试验，“Type1”交换机将具有一个新的功能集合。
在一条规则中，可以根据网络包在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规范主要分为如下四大部分，
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设备中存在。
2. OpenFlow的FlowTable(国内有直译为“流表”的)
OpenFlow通过用户定义的或者预设的规则来匹配和处理网络包。一条OpenFlow的规则由匹配域(Match Fields)、优先级(Priority)、处理指令(Instructions)和统计数据(如Counters)等字段组成，如下图所示。
Openflow的思路很简单，网络设备维护一个FlowTable并且只按照FlowTable进行转发，Flowtable本身的生成、维护、下发完全由外置的Controller来实现，注意这里的FlowTable并非是指IP五元组，事实上OpenFlow 1.0定义的了包括端口号、VLAN、L2/L3/L4信息的10个关键字，但是每个字段都是可以通配的，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么流表中就可以只有目的IP字段是有效的，其它全为通配。
这种控制和转发分离的架构对于L2交换设备而言，意味着Controller将负责二层MAC学习，VLAN划分，还要负责三层路由协议的学习，最后下发给路由器和交换机，对于L3设备，各类IGP/EGP路由运行在Controller之上，Controller根据需要下发流表（对于L3应该是路由表）给相应的路由器。
流表的下发方式有两种模式:
主动： Controller将自己收集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发；
被动：是指网络设备收到一个报文没有匹配的FlowTable记录时，将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，故可以大大节省TCAM空间。当一个Controller同时控制多个交换机/路由器设备时，它们看起来就像一个大的逻辑交换机，各个交换机/路由器硬件就如同这个逻辑网络设备的远程线卡，类似的概念在Cisco的Nexus 1000/1000v、ASR9000/9000v和Juniper的Q-Fabric架构中可以看到影子，Cisco称之为nV(Network Virtualization)技术。
OpenFlow之下的网络架构组成:
目前主要的OpenFlow解决方案包含一个三层架构，第一层架构由关键的具备OpenFlow 协议许可的以太网交换机组成。通常情况下，它们是具备OpenFlow功能的物理以太网交换机。我们还能看到一些具备OpenFlow功能的虚拟层/软件交换机和路由器。今后这类设备肯定会越来越多。
然后是两层服务器端软件：OpenFlow控制器和OpenFlow软件应用建立在控制器顶端。
控制器是一个平台，该平台向下可以直接与使用OpenFlow协议的交换机进行对话。向上，控制器可为OpenFlow软件应用提供大量功能，包括将交换机资源编入统一的网络视窗内，为应用提供协同和通用库。
在顶层，OpenFlow软件应用为网络执行实际控制功能，如交换与路由。应用是写在由控制器提供的统一网络视窗和通用库顶层的简单软件。因此，这些应用能够着重执行特定控制算法，并能够调整其下层的OpenFlow层以实例化网络中的算法。
目前，OpenFlow术语有两个意思，可以指“OpenFlow协议”，明确指称用于网络的x86指令集，也可以指“OpenFlow架构”，主要是交换机、控制器和应用层。
SDN与网络虚拟化:
参考摘录:https://www.sdnlab.com/15475.html
SDN不是网络虚拟化，网络虚拟化也不是SDN。
SDN是一种集中控制的网络架构，可将网络划分为数据层面和控制层面。
在数据中心等场景中，为实现快速部署和动态调整，必须使用自动化的业务部署。SDN的出现给网络虚拟化业务部署提供了新的解决方案。通过集中控制的方式，网络管理员可以通过控制器的API来编写程序，从而实现自动化的业务部署，大大缩短业务部署周期，同时也实现随需动态调整。
网络虚拟化是一种网络技术，可以在物理拓扑上创建虚拟网络。
传统的网络虚拟化部署需要手动逐跳部署，其效率低下，人力成本很高。
SDN实现网络虚拟化需要完成三部分工作: 物理网络管理，网络资源虚拟化和网络隔离
虚拟化平台
虚拟化平台是介于数据网络拓扑和租户控制器之间的中间层。面向数据平面，虚拟化平面就是控制器，而面向租户控制器，虚拟化平台就是数据平面。所以虚拟化平台本质上具有数据平面和控制层面两种属性。在虚拟化的核心层，虚拟化平台需要完成物理网络资源到虚拟资源的虚拟化映射过程。面向租户控制器，虚拟化平台充当数据平面角色，将模拟出来的虚拟网络呈现给租户控制器。从租户控制器上往下看，只能看到属于自己的虚拟网络，而并不了解真实的物理网络。而在数据层面的角度看，虚拟化平台就是控制器，而交换机并不知道虚拟平面的存在。所以虚拟化平台的存在实现了面向租户和面向底层网络的透明虚拟化，其管理全部的物理网络拓扑，并向租户提供隔离的虚拟网络。
虚拟化平台不仅可以实现物理拓扑到虚拟拓扑“一对一”的映射，也应该能实现物理拓扑“多对一”的映射。而由于租户网络无法独占物理平面的交换机，所以本质上虚拟网络实现了“一虚多”和“多虚一”的虚拟化。此处的“一虚多”是指单个物理交换机可以虚拟映射成多个虚拟租户网中的逻辑交换机，从而被不同的租户共享；“多虚一”是指多个物理交换机和链路资源被虚拟成一个大型的逻辑交换机。即租户眼中的一个交换机可能在物理上由多个物理交换机连接而成。
网络资源虚拟化
为实现网络虚拟化，虚拟化平台需要对物理网络资源进行抽象虚拟化，其中包括 拓扑虚拟化，节点资源虚拟化和链路资源虚拟化
• 拓扑虚拟化【核心: 将物理节点映射给一个或多个用户/租户】
拓扑虚拟化是网络虚拟化平台最基本的功能。虚拟平台需要完成租户虚网中的虚拟节点和虚拟链路到物理节点和链路的映射。其中包括“一对一”和“一对多”的映射。
“一对一”的映射中，一个虚拟节点将会映射成一个物理节点，同理虚拟链路也是。
“一对多”的映射中，一个虚拟节点可以映射成由多个连接在一起的物理节点；一条逻辑链路也可能映射成由链接在一起的多条链路。而对于物理节点而言，一个物理节点可以被多个逻辑节点映射。
• 节点资源虚拟化【核心: 控制每个用户/租户能使用物理设备上多少资源】
节点资源的虚拟化包括对节点Flow tables（流表）、CPU等资源的抽象虚拟化。
流表资源本身是交换机节点的稀缺资源，如果能对其进行虚拟化，然后由虚拟化平台对其进行分配，分配给不同的租户，那么就可以实现不同租户对节点资源使用的分配和限制。拓扑抽象仅仅完成了虚拟节点到物理节点的映射，而没有规定不同用户/租户对物理节点资源使用的分配情况。若希望进行更细粒度的网络虚拟化，节点资源虚拟化非常有必要。
• 链路资源虚拟化【核心: 控制不同用户/租户能使用多少链路带宽，端口队列长度】
和节点资源一样，链路资源也是网络中重要的资源，而拓扑抽象并没有规定某些用户可使用的链路资源的多少。所以在进行更细粒度的虚拟化时，有必要对链路资源进行虚拟化，从而实现链路资源的合理分配，这样就能够抽象虚拟化的链路资源包括租户可使用的带宽以及端口的队列资源等等。
网络隔离
网络资源虚拟化仅仅完成了物理资源到虚拟资源的抽象过程，为实现完全的网络虚拟化，还需要对不同的租户提供隔离的网络资源。网络隔离需要对SDN的控制平面和数据平面进行隔离，从而保证不同租户控制器之间互补干扰，不同虚网之间彼此隔离。此外，为了满足用户对地址空间自定义的需求，虚拟化平台还需要对网络地址进行虚拟化。
控制面隔离
控制器的性能对SDN整体的性能产生极大的影响，所以虚拟化平台需保证租户的控制器在运行时不受其他租户控制器的影响，保证租户对虚拟化平台资源的使用。虚拟化平台在连接租户控制器时需保证该进程可以得到一定的资源保障，比如CPU资源。而虚拟化平台本身所处的位置就可以轻易实现租户的控制器之间的相互隔离。
数据面隔离
数据面的资源包括节点的CPU、Flow Tables等资源以及链路的带宽，端口的队列资源等。为保证各个租户的正常使用，需对数据面的资源进行相应的隔离，从而保证租户的资源不被其他租户所占据。若在数据面上不进行资源的隔离，则会产生租户数据在数据面上的竞争，从而无法保障租户对网络资源的需求，所以很有必要在数据面对资源进行隔离。
地址隔离
为使租户能在自己的虚拟租户网中任意使用地址，虚拟化平台需要完成地址的隔离。实现地址隔离主要通过地址映射来完成。租户可任意定制地址空间，而这些地址对于虚拟化平台而言是面向租户的虚拟地址。虚拟化平台在转发租户控制器南向协议报文(即:发送的报文)时，需要将虚拟地址转化成全网唯一的物理地址。租户的服务器的地址在发送到接入交换机时就会被修改成物理地址【注意: 这里不是NAT转换地址，而是通过FlowTable来修改报文字段的】，然后数据包的转发会基于修改之后的物理地址进行转发。当数据到达租户目的地址主机出端口，控制器需将地址转换成原来租户设定的地址，从而完成地址的虚拟化映射。地址的虚拟化映射使得租户可以使用完全的地址空间，可以使用任意的FlowSpace（流空间：流表匹配项所组成的多维空间），而面向物理层面则实现了地址的隔离，使得不同的租户使用特定的物理地址，数据之间互不干扰。
关于SDN的摘录补充：
它的核心是SDN拥有一个集中或分布式智能实体，它具有网络的整体视图，可以根据该视图做出路由和切换决策，”Capuano说。“通常，网络路由器和交换机只知道它们的相邻网络设备。但是，通过正确配置的SDN环境，该中央实体可以控制一切，从而轻松更改策略，简化整个企业的配置和自动化。“
通常在SDN环境中，客户可以看到他们所有的设备和TCP流，这意味着他们可以从数据或管理平面切断网络，以支持各种应用和配置，Capuano说。因此，用户可以根据需要更轻松地从生产环境中对IoT应用程序进行细分。
一些SDN控制器能够智能地“看到”网络正在变得拥挤。作为响应，SDN控制器将增加带宽或做出其他处理，以确保远程和边缘组件不会受到延迟影响。
网络可以分为两部分，一部分可以是面向公众的低安全性网络，在这部分网络中不会触及任何敏感信息。另一个细分的网络可以通过基于软件的防火墙和加密策略实现更细粒度的远程访问控制，允许敏感数据在该网络上传输。“例如，如果客户拥有一个物联网组，但该网络在安全性方面并不是那么成熟，通过SDN控制器，您可以将该组从企业关键流量中分离出来，”Capuano说。“SDN用户可以在网络范围内推出从数据中心到边缘的安全策略，如果你在白盒子上完成所有这些工作，部署可以比传统设备便宜30-60％。
OpenFlow实现上面架构的核心:
OpenFlow规范实际上是一整套软件应用程序接口，控制网络数据如何转发，可基于硬件实现，OpenFlow增加了定制转发数据的控制程度，减少了支撑复杂控制所需的硬件成本。OpenFlow网络控制节点可以通过规范与支持OpenFlow的交换节点沟通配置信息，决定数据转发平面的转发表，控制器与转发节点间通过SSL加密传输。OpenFlow支持定义的“信息流”主要是从1层到4层的关键信息包括端口号、VLAN、MAC、以太网包头、IP地址、 IP协议号、TCP端口号等。配置信息通常包括“信息流”和与之对于的动作。每个“信息流”有符合某种特征的数据包及动作组成，比如源IP/源Port，目的IP/目的Port，5种不同转发动作。
OpenFlow架构图:
OpenFlow “信息流”定义:
用户可以通过OpenFlow预设通用规则，每种不同网络节点可以根据设备特点更新转发平面规则，比如转发交换机更新MAC地址转发表、VLAN端口转发表、1到4层转发表，路由器修改访问控制IP列表，防火墙修改进出端口规则等。
这里就是OpenFlow可定义规则的10元组：
OpenFlow它增加了网络灵活控制能力，位于底层的分布式网络设备节点的智能性通过OpenFlow指令得以实现，集中式的OpenFlow Controller节点的实时控制底层物理网络的变化，并为各个分布式物理节点生成快速转发表，而无须各个物理节点进行复杂智能分析计算，它们就可专心执行网络转发平面的功能。当新的转发节点加入到OpenFlow网络时，自动从中央控制节点得的最新网络配置信息，完成网络自动化感知。而中央控制节点基于x86标准服务器架构，强大计算能力和横向扩展特性保证了控制平面扩展性和经济性。
OpenFlow独立控制平面的出现，TRILL或Shortest Path Bridging协议变得不是那么重要，因为OpenFlow控制器可以拥有有全网视图，所以动态防止环路发生。OpenFlow不但提高了传统转发平面的效率，在提供高级网络服务方面还可以展现独特的价值，比如多对一的网络虚拟化，分布式负载均衡和分布式防火墙或入侵检测，非常不同于传统模式的一对多网络虚拟化模式。每一类分布式网络资源服务与单独云租户对应，每个云租户都有独立的跨物理节点的虚拟化网络，比如不同虚拟网络交换机，对不同租户管理员来说，它所对应的物理网络端口是透明，逻辑化网络派生于在物理网络资源上抽象出的虚拟网络资源池。虚拟机移动后，当虚拟机相应“信息流”的第一个数据包到达移动后的本地(物理/虚拟)交换机节点，如果本地交换机节点没有发现匹配的转发规则，整个数据报文会被送到中央管理节点，中央管理节点根据定义转发规则逻辑下发相应的转发规则，并应用到本地交换机的转发表建立新的匹配项，之后的“信息流”不再通过管理节点，由转发节点直接完成。
OpenFlow的应用
随着OpenFlow/SDN概念的发展和推广，其研究和应用领域也得到了不断拓展。目前，关于OpenFlow/SDN的研究领域主要包括网络虚拟化、安全和访问控制、负载均衡、聚合网络和绿色节能等方面。另外，还有关于OpenFlow和传统网络设备交互和整合等方面的研究。
下面将举几个典型的研究案例来展示OpenFlow的应用。
1. 网络虚拟化 – FlowVisor
网络虚拟化的本质是要能够抽象底层网络的物理拓扑，能够在逻辑上对网络资源进行分片或者整合，从而满足各种应用对于网络的不同需求。为了达到网络分片的目的，FlowVisor实现了一种特殊的OpenFlow Controller，可以看作其他不同用户或应用的Controllers与网络设备之间的一层代理。
因此，不同用户或应用可以使用自己的Controllers来定义不同的网络拓扑，同时FlowVisor又可以保证这些Controllers之间能够互相隔离而互不影响。
用计算机的虚拟化来类比，则FlowVisor就是位于硬件结构元件和软件之间的网络虚拟层。FlowVisor允许多个控制同时控制一台OpenFlow交换机，但是每个控制器仅仅可以控制经过这个OpenFlow交换机的某一个虚拟网络（即slice）。因此通过FlowVisor建立的试验平台可以在不影响商业流的转发速度的情况下，允许多个网络试验在不同的虚拟网络上同时进行。FlowVisor与一般的商用交换机是兼容的，而不需要使用FPGA和网络处理器等可编程硬件。
下图展示了使用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的面临的难题和优势【摘录片段】
OpenFlow 1.0的流表分为Match Fields、计数器和指令集三个部分，Match Fields是报文匹配的输入关键字，计数器是管理所需，指令集是决定报文如何转发，最基本的转发行为包括转发给某个端口、封装改写报文后转发以及丢弃。OpenFlow 1.1增加了对MPLS以及UDP/SCTP传输层协议的支持，同时针对流表开销过大的情况设计了多级流表，并增加分组策略功能。
openflow的价值到底在哪里，是Open还是Flow？这个问题首先可以否认”Flow”的价值，原因很简单，是否控制到细粒度的Flow取决于应用，应用没有控制流的需求，则Flow毫无价值，”Flow”只是Openflow能提供的最大限度的控制能力而已，目前在ONF关注的数据中心交换网中没有谁打算控制精确到n(n>=5)元组的流，除非是应用在防火墙控制上。
那么”Open”呢？的确包括Nick本人在内一直强调的都是”Open”是价值之所在，Open之后，研究者、运营商可以采购任意厂商的标准接口设备，自己DIY网络，甚至可以采用交换信息厂商提供的公版设计交换机加上OpenFlow Controller就可以组成自己所需的网络，并且Controller的开放软件架构使得网络控制的实现就像Web编程一样简单，采用Python、JAVA Script这样的脚本加上开源算法库、一个不需要了解太多网络协议细节的开发者几天就可以实现一个新的网络拓扑算法开发、部署。这在流量模型尤为复杂运营级数据中心确实非常有吸引力。在这样的一种场景中，网络设备市场就变成了如同PC那样的市场，卖网络设备硬件的就成了卖大白菜的，大家最后只能比拼价格和工艺设计了。但是，即使这种悲惨的场景成为事实，谁又会是PC化的网络市场中提供Windows的微软呢，Openflow体系的NOS（Network OS）将会谁是赢家？交换网络相对简单，但是L3之上各种协议散落在数十年积累的数千篇IETF RFC中，谁能够有实力实现一个如此复杂的网络操作系统而又让运营商放心呢？我想仍然可能是今天的网络设备巨头Cisco、Juniper们，产生意外的可能极小。
Arista定义了软件定义云网络的四大“支柱：云拓扑、分布式控制、网络虚拟化和管理/自动化。OpenFlow只是实现基于控制器的SDN管理/自动化支柱中的多种方法中的一种而已。其他的实现方法还有CLI、SNMP、XMPP、Netconf、OpenStack、VMware vSphere虚拟化软件等等。
在今年的VMworld大会上，Arista演示了如何用虚拟机的简单预配置来构建云，利用其EOS操作系统软件和CloudVision接口最多可实现5万个网络节点。XMPP是其CloudVision中的API。
“没有任何理由认为，明天不会出现一个OpenFlow或者OpenStack API，Ullal说。“但是现在就有一个完善定义的接口。我们今天用Netconf和XMPP，就是因为它很容易实现，各种规范定义完善，而且我们的一些客户对此很感兴趣。
原文地址：https://www.cnblogs.com/wn1m/p/11281781.html