目录(?)[-]

简介
编辑本段传统路由器的设计
设计思想
1. 虚拟化的逆袭网络虚拟化之OpenFlow和SDN
Open还是Flow
OpenFlow对产业链的影响
OpenFlow面临的技术难点
结论
OpenFlow并非实现网络变革的唯一途径
1. 世界首个大型100G OpenFlow SDN网络接近完成
从操作系统到网络操作系统
实现技术探讨
1. 模型
2. 通用性标准
3. 架构
  1. 组件
  2. 操作
  3. 多粒度处理
  4. 应用实现
  5. 系统库
相关工作

简介

　　软件定义网络（Software Defined Network, SDN ），是由美国斯坦福大学clean slate研究组提出的一种新型网络创新架构，其核心技术OpenFlow通过将网络设备控制面与数据面分离开来，从而实现了网络流量的灵活控制，为核心网络及应用的创新提供了良好的平台。

编辑本段 传统路由器的设计

　　从路由器的设计上看，它由软件控制和硬件数据通道组成。软件控制包括管理(CLI,SNMP)以及路由协议(OSPF,ISIS,BGP)等。数据通道包括针对每个包的查询、交换和缓存。这方面有大量论文在研究，引出三个开放性的话题，即“提速2倍”，确定性的(而不是概率性的)交换机设计，以及让路由器简单。

　　事实上在路由器设计方面我们已经迷失了方向，因为有太多的复杂功能加入到了体系结构当中，比如OSPF，BGP，组播，区分服务，流量工程，NAT，防火墙，MPLS，冗余层等等。个人认为，我们在20世纪60年代定义的“哑的，最小的”数据通路已经臃肿不堪。

设计思想

　　因此我们需要做以下几件事：　　1. 在底层和开放编程环境之间要有一个清晰的分割；　　2. 设计一个简单的硬件底层，能够包括和简化当前的底层; 　　3. 极少的使用事先形成的有关底层如何被编程的想法；　　4. 强隔离。　　在设计硬件底层方面，我们要用最少的基于流的数据通路来缓存决策，也即实现一个基于流的底层。我们需要对流进行灵活的定义，如单播、组播、导航点、负载均衡，并且支持不同类型的流的聚类；我们需要控制流，把流作为编程的实体：能对它路由、私有化、移动……我们还要吸取包交换的益处，因为它切实可行，能全局部署，而且很有效率——当然是在它很简单的时候。　　综合上述考虑，我们定义了一个名为“流空间”的底层，它有以下属性：　　1. 后向兼容。当前的分层结构是它的一个特例，而且端点不需要修改；　　2. 容易在硬件上部署，比如在每个交换机上部署TCAM流表；　　3. 流之间能清晰分离，具有简单的几何结构，能证明哪个流能或者不能通讯。　　作为底层，它有以下属性：　　第一，基于流；第二，对每个流只有少量的动作，如转发给端口；转发给控制器；重写头，在流空间之间路由；根据最小/最大速率分隔带宽等；第三，外部的针对流表的开放API。

开放网络基金会(ONF)

FlowVisor是建立在OpenFlow之上的网络虚拟化平台，它可以将物理网络分成多个逻辑网络，从而实现开放软件定义网络（SDN）。它为管理员提供了广泛定义规则来管理网络，而不是通过调整路由器和交换机来管理网络。

FlowVisor安装在商品硬件上，它是一个特殊的OpenFlow控制器，主要是作为OpenFlow交换机网络和其他标准OpenFlow控制器之间的透明代理。虽然FlowVisor仍被认为处于试验阶段，并且缺乏一些基本功能（例如命令行管理工具），但FlowVisor已经被部署在很多生产环境中，例如从2009年开始应用于斯坦福大学的校园网络。

FlowVisor通过抽象层来分割物理网络，它位于一组交换机和软件定义网络或多个网络之间，管理带宽、CPU利用率和流量表，这类似于管理程序位于服务器硬件和软件之间，以允许多个虚拟操作系统运行。

正如管理程序依赖于标准x86指令来虚拟化服务器一样，FlowVisor使用标准OpenFlow指令集来管理OpenFlow交换机，这些指令设置了低级别规则，比如如何基于数据包表头中的特点来转发数据包。

由于所有这些规则都是通过流量表定义的，因此，无论是从带宽还是CPU使用率来看，网络虚拟化都没有增加很多开销或者几乎没有增加开销，不过另外需要设置和修改流量表规则的单独的带外物理控制器。

切片

FlowVisor网络的基本要素是网络切片，网络切片是由一组文本配置文件来定义的。文本配置文件包含控制各种网络活动的规则，例如允许、只读和拒绝，其范围包括流量的来源IP地址、端口号或者数据包表头信息。

例如，网络管理员可以将安全的Telnet流量（默认端口992）分配到其自身的切片，将执行团队IP地址的流量分配到另一个切片。然后他可以创建第三个默认切片来管理所有其他流量，把它当做“只读”切片来监控其他三个切片，以达到诊断目的。网络管理员可以动态地重新分配和管理这些切片，以确保浏览YouTube的人不会对Telnet应用程序和执行团队带宽造成负面影响。

切片隔离是FlowVisor虚拟化的重要组成部分，但它仍然在处于发展中。在近日发表的一篇描述FlowVisor愿景和部署的学术文章中，作者呼吁进行严密的交换机与CPU隔离，但由于目前只能通过OpenFlow对交换机CPU进行间接管理，导致该功能被限制。鉴于这些限制和功能，FlowVisor按照以下五个规格（出自该OpenFlow技术报告）来进行虚拟化和隔离：

◆带宽：每个切片应该具有专门的总可用带宽百分比。

◆拓扑结构：每个切片对于网络节点（包括物理和虚拟交换机及路由器）应该有自己的“看法”。切片的组成部分应该是不知道切片的：对于控制器而言，FlowVisor看起来就是普通的交换机；从OpenFlow交换机的角度来看，FlowVisor就是一个控制器。

◆流量：根据上述规则设置，流量应该严密地始终如一地隔离到一个特定切片或者多个切片。

◆设备CPU：重载物理交换机可以丢掉缓慢路径的数据包。网络管理员会更新OpenFlow统计计数器和规则，所以在评定限速密集命令时，FlowVisor应该考虑CPU资源。

◆转发表：由于转发表往往被限定在物理设备上，网络管理员应确保一个切片不会影响任何特定设备的转发表，迫使它放弃另一切片的规则。

FlowVisor准备好迎接广泛应用了吗？

与其构建块OpenFlow一样，FlowVisor能够帮助研究人员快速灵活地在大型生产环境对新的SDN理念和工具进行实验。目前FlowVisor被部署在美国各地的生产环境中，特别是在大型校园（例如斯坦福）。此外，两个以研究为重点的大型网络--全球网络创新环境（GENI）和Internet2的参与者也在使用FlowVisor。

然而，这并不意味着FlowVisor即将出现在你附近的业务网络中。斯坦福大学博士后研究员、开放网络实验室员工兼FlowVisor开发人员Ali Al-Shabibi表示，虽然该平台非常稳定，但仍然有很长的路要走。

他表示：“在FlowVisor投入企业环境使用之前，仍有大量工作需要做。”首先，它需要提高最终用户的易用性。例如，目前它没有即时命令行界面或者基于Web的管理，让用户不得不管理配置文件来做出调整。

FlowVisor的网络虚拟化用例

Rob Sherwood在斯坦福大学领导了三年FlowVisor开发工作，现任职于OpenFlow初创公司Big Switch Networks公司，他表示，FlowVisor的价值很好地从实验网络扩展到了实用服务，例如服务供应商可以向其客户提供的即插即用优化服务。想象一下，为你提高视频下载速度的强化视频流，或者用于VoIP的专用切片，但为了获取这些服务，你需要向互联网服务供应商支付额外费用。

Sherwood表示，对于想要更有效地或者更安全地管理大量流量的大型互联网公司，FlowVisor也非常适用。“例如你可以象一下谷歌公司，他们拥有多个内部服务，他们通过相同网络发送Gmail流量和YouTube流量，但分别使用不同的政策，”他表示，“目前他们使用不同的物理网络，因为他们不能说，‘YouTube用这个路径，Gmail用那个路径。’”

FlowVisor网络虚拟化的风险和优势

获取定义和重新定义网络的颗粒度功能是要付出一定代价的。Infonetics公司的数据中心和云分析师Sam Barnett认为对于大多数IT企业而言，这个代价太高了。

“如果你将OpenFlow交给未受过相关教育的社区，这就类似于将上膛的枪交给小孩，并告诉他们瞄准自己和扣动扳机，”他警告说，“而对于运营商而言，OpenFlow有着巨大的优势。例如，我曾在MCI（运营商）工作多年，如果当时我们有OpenFlow，将能帮助我们解决很多问题。”

Barnett表示，除了运营商和最大胆的网络尝试者外，对于大多数企业而言，为了获得这样的灵活性，会招致太多麻烦，得不偿失。Al-Shabibi同意他的看法，但他指出企业有其他商业解决方案来利用这项技术。

他表示：“规模较小的IT企业可能不会开发自己的解决方案，但他们可以找Big Switch、Nicira或其他OpenFlow兼容供应商购买解决方案，然后将解决方案部署到其网络中。”

FlowVisor网络的光明前景

Al-Shabibi指出，由于采用FlowVisor是建立在OpenFlow控制器成功的基础上的。这两者的普及率都可能持续增长。“我们希望看到OpenFlow更多地被行业所接受，FlowVisor同样如此，”他表示，“这真的是SDN的‘杀手级应用’之一，将你网络中的服务进行隔离真的是非常棒的功能。”

Sherwood表示，FlowVisor的影响力可能最终也与OpenFlow相同。 “我们正试图将大家注意力聚焦在FlowVisor代码上，”他指出该项目还引入一名谷歌代码夏令营实习生来帮助改善和提高其知名度，“随着环境不断完善，人们将会看到网络切片的价值。”

基于OpenFlow实现SDN（Software Defined Network）。在SDN中，交换设备的数据转发层和控制层是分离的，因此网络协议和交换策略的升级只需要改动控制层。OpenFlow在OpenFlow交换机上实现数据转发，而在控制器上实现数据的转发控制，从而实现了数据转发层和控制层的分离。基于OpenFlow实现SDN，则在网络中实现了软硬件的分离以及底层硬件的虚拟化，从而为网络的发展提供了一个良好的发展平台。

OpenFlow网络由OpenFlow交换机、FlowVisor和Controller三部分组成。OpenFlow交换机进行数据层的转发；FlowVisor对网络进行虚拟化；Controller对网络进行集中控制，实现控制层的功能。OpenFlow网络的结构示意图如下：

　　OpenFlow交换机　　OpenFlow交换机是整个OpenFlow网络的核心部件，主要管理数据层的转发。OpenFlow交换机接收到数据包后，首先在本地的流表上查找转发目标端口，如果没有匹配，则把数据包转发给Controller，由控制层决定转发端口。　　OpenFlow交换机的组成　　OpenFlow交换机由流表、安全通道和OpenFlow协议三部分组成。

　　安全通道是连接OpenFlow交换机到控制器的接口。控制器通过这个接口控制和管理交换机，同时控制器接收来自交换机的事件并向交换机发送数据包。交换机和控制器通过安全通道进行通信，而且所有的信息必须按照OpenFlow协议规定的格式来执行。　　OpenFlow协议用来描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。协议的核心部分是用于OpenFlow协议信息结构的集合。　　OpenFlow协议支持三种信息类型：Controller-to-Switch，Asynchronous和Symmetric，每一个类型都有多个子类型。Controller-to-Switch信息由控制器发起并且直接用于检测交换机的状态。Asynchronous信息由交换机发起并通常用于更新控制器的网络事件和改变交换机的状态。Symmetric信息可以在没有请求的情况下由控制器或交换机发起。　　OpenFlow交换机的分类　　按照对OpenFlow的支持程度，OpenFlow交换机可以分为两类：专用的OpenFlow交换机和支持OpenFlow的交换机。　　专用的OpenFlow交换机是专门为支持OpenFlow而设计的。它不支持现有的商用交换机上的正常处理流程，所有经过该交换机的数据都按照OpenFlow的模式进行转发。专用的OpenFlow交换机中不再具有控制逻辑，因此专用的OpenFlow交换机是用来在端口间转发数据包的一个简单的路径部件。　　支持OpenFlow的交换机是在商业交换机的基础上添加流表、安全通道和OpenFlow协议来获得了OpenFlow特性的交换机。其既具有常用的商业交换机的转发模块，又具有OpenFlow的转发逻辑，因此支持OpenFlow的交换机可以采用两种不同的方式处理接收到的数据包。　　按照OpenFlow交换机的发展程度来分，OpenFlow交换机也可以分为两类：“Type0”交换机和“Type1”交换机。　　“Type0”交换机仅仅支持十元组以及以下四个操作：转发这个流的数据包给一个给定的端口（或者几个端口）；压缩并转发这个流的数据包给控制器；丢弃这个流的数据包；通过交换机的正常处理流程来转发这个流的数据包。　　显然“Type0”交换机的这些功能是不能满足复杂试验要求的，因此我们将要定义“Type1”交换机来支持更多的功能，从而支持复杂的网络试验。“Type1”交换机将具有一个新的功能集合。　　支持网络虚拟化的FlowVisor 　　类比计算机的虚拟化，FlowVisor就是位于硬件结构元件和软件之间的网络虚拟层。FlowVisor允许多个控制同时控制一台OpenFlow交换机，但是每个控制器仅仅可以控制经过这个OpenFlow交换机的某一个虚拟网络（即slice）。因此通过FlowVisor建立的试验平台可以在不影响商业流的转发速度的情况下，允许多个网络试验在不同的虚拟网络上同时进行。FlowVisor与一般的商用交换机是兼容的，而不需要使用FPGA和网络处理器等可编程硬件。　　Controller 　　OpenFlow实现了数据层和控制层的分离，其中OpenFlow交换机进行数据层的转发，而Controller实现了控制层的功能。Controller通过OpenFlow协议这个标准接口对OpenFlow交换机中的流表进行控制，从而实现对整个网络进行集中控制。Controller的这一切功能都要通过运行NOX来实现，因此NOX就像是OpenFlow网络的操作系统。此外，在NOX上还可以运行Plug-n-serve、OpenRoads以及OpenPipes等应用程序。　　Plug-n-Serve 通过规定数据传输路径来控制网络以及服务器上的负载，从而使得负载均衡并降低响应时间。OpenRoads 是支持OpenFlow无线网络移动性研究的框架。OpenPipes 可以在网络系统中通过移动每个子模块来测试每个子模块，并可以决定如何划分设计单元。

虚拟化的逆袭：网络虚拟化之OpenFlow和SDN

发表于：2012年07月24日 11:376

EMC中国研究院万林涛

从网络虚拟化说起

云计算的发展，是以虚拟化技术为基础的。云计算服务商以按需分配为原则，为客户提供具有高可用性、高扩展性的计算、存储和网络等IT资源。虚拟化技术将各种物理资源抽象为逻辑上的资源，隐藏了各种物理上的限制，为在更细粒度上对其进行管理和应用提供了可能性。近些年，计算的虚拟化技术（主要指x86平台的虚拟化）取得了长足的发展；相比较而言，尽管存储和网络的虚拟化也得到了诸多发展，但是还有很多问题亟需解决，在云计算环境中尤其如此。

OpenFlow和SDN尽管不是专门为网络虚拟化而生，但是它们带来的标准化和灵活性却给网络虚拟化的发展带来无限可能。笔者希望通过本文对OpenFlow/SDN做一个初步介绍，以期帮助大家能够进一步深入了解和学习OpenFlow/SDN。限于笔者能力有限，文中难免纰漏错误之处，欢迎批评和指正。

起源与发展

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）于今年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在学术界和工业界都做了很好的介绍和推广。今年年初召开的第二届峰会上，来自Google的Urs Hölzle在以OpenFlow@Google[7]为题的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)。下图[8] 列出了OF和OF-CONFIG规范各个版本的发展历程及变化，从图中可以看到目前使用和支持最多的仍然是1.0和1.1版本。

在这里，我们将详细介绍一下OpenFlow Switch的最新规范（即OF-1.3）[9]。下图选自Nick等人的论文OpenFlow：EnablingInnovation in Campus Networks [4] 。这张图常被用来说明OpenFlow的原理和基本架构。其实，这张图还很好地表明了OpenFlow Switch规范所定义的范围—从图上可以看出，OpenFlow Switch规范主要定义了Switch的功能模块以及其与Controller之间的通信信道等方面。

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的定义，以及规则的超时处理等。

3. 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之间的信道加密、如何建立多连接等（主连接和辅助连接）。

4. OpenFlow协议及相关数据结构

在OpenFlow规范的最后一部分，主要详细定义了各种OpenFlow消息的数据结构，包括OpenFlow消息的消息头等。这里就不一一赘述，如需了解可以参考OpenFlow源代码[10]中openflow.h头文件中关于各种数据结构的定义。

OpenFlow的应用

随着OpenFlow/SDN概念的发展和推广，其研究和应用领域也得到了不断拓展。目前，关于OpenFlow/SDN的研究领域主要包括网络虚拟化、安全和访问控制、负载均衡、聚合网络和绿色节能等方面。另外，还有关于OpenFlow和传统网络设备交互和整合等方面的研究。

下面将举几个典型的研究案例来展示OpenFlow的应用。

1. 网络虚拟化 – FlowVisor[11]

网络虚拟化的本质是要能够抽象底层网络的物理拓扑，能够在逻辑上对网络资源进行分片或者整合，从而满足各种应用对于网络的不同需求。为了达到网络分片的目的，FlowVisor实现了一种特殊的OpenFlow Controller，可以看作其他不同用户或应用的Controllers与网络设备之间的一层代理。因此，不同用户或应用可以使用自己的Controllers来定义不同的网络拓扑，同时FlowVisor又可以保证这些Controllers之间能够互相隔离而互不影响。下图展示了使用FlowVisor可以在同一个物理网络上定义出不同的逻辑拓扑。FlowVisor不仅是一个典型的OpenFlow应用案例，同时还是一个很好的研究平台，目前已经有很多研究和应用都是基于FlowVisor做的。

2. 负载均衡 – Aster*x[12]

传统的负载均衡方案一般需要在服务器集群的入口处，通过一个gateway或者router来监测、统计服务器工作负载，并据此动态分配用户请求到负载相对较轻的服务器上。既然网络中所有的网络设备都可以通过OpenFlow进行集中式的控制和管理，同时应用服务器的负载可以及时地反馈到OpenFlowController那里，那么OpenFlow就非常适合做负载均衡的工作。Aster*x通过Host Manager和Net Manager来分别监测服务器和网络的工作负载，然后将这些信息反馈给FlowManager，这样Flow Manager就可以根据这些实时的负载信息，重新定义网络设备上的OpenFlow规则，从而将用户请求（即网络包）按照服务器的能力进行调整和分发。

3. 绿色节能的网络服务 – ElasticTree[13]

在数据中心和云计算环境中，如何降低运营成本是一个重要的研究课题。能够根据工作负荷按需分配、动态规划资源，不仅可以提高资源的利用率，还可以达到节能环保的目的。ElasticTree创新性地使用OpenFlow，在不影响性能的前提下，根据网络负载动态规划路由，从而可以在网络负载不高的情况下选择性地关闭或者挂起部分网络设备，使其进入节电模式达到节能环保、降低运营成本的目的。

结语

没有任何一项技术可以解决所有问题，我们相信OpenFlow/SDN也不会是解决现有所有网络问题的“万金油”。但是，我们相信OpenFlow/SDN的确给网络变革和创新带了许多机遇—既然网络问题已经变得可以通过编程来解决的时候，技术宅们该出手了，拯救网络世界的时候到了！

参考资料

[1]斯坦福大学Clean Slate项目网站, http://cleanslate.stanford.edu/

[2] Ethane项目首页，http://yuba.stanford.edu/ethane/

[3] Sane项目首页，http://yuba.stanford.edu/sane/

[4] OpenFlow: EnablingInnovation in Campus Networks， www.openflow.org/documents/openflow-wp-latest.pdf

[5] TechnologyReview网站关于2009年十大前沿技术的评选，http://www.technologyreview.com/article/412194/tr10-software-defined-networking/

[6] Software DefinedNetworking: The New Norm for Networks,https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf

[7] Open Networking Summit2012日程安排，http://opennetsummit.org/speakers.html

[8] SDN Standards: What andWhatnot, http://opennetsummit.org/talks/ONS2012/pitt-tue-standards.pdf

[9] OpenFlow SwitchSpecification v1.3.0,https://www.opennetworking.org/images/stories/downloads/specification/openflow-spec-v1.3.0.pdf

[10] OpenFlow v1.0.0源代码， http://openflowswitch.org/downloads/openflow-1.0.0.tar.gz

[11] FlowVisor: A Network Virtualization Layer,

http://www.openflow.org/downloads/technicalreports/openflow-tr-2009-1-flowvisor.pdf

[12]Aster*x:Load-Balancing as a Network Primitive,

http://www.stanford.edu/~nikhilh/pubs/handigol-acld10.pdf

[13] ElasticTree: Saving Energy in Data Center Networks,

http://static.usenix.org/event/nsdi10/tech/full_papers/heller.pdf

OpenFlow是由斯坦福大学的Nick McKeown教授在2008年4月ACM Communications Review上发表的一篇论文OpenFlow: enabling innovation in campus networks首先详细论述了OpenFlow的原理。由该论文课题可知OpenFlow提出的最初出发点是用于校园内网络研究人员实验其创新网络架构、协议，考虑到实际的网络创新思想需要在实际网络上才能更好地验证，而研究人员又无法修改在网的网络设备，故而提出了OpenFlow的控制转发分离架构，将控制逻辑从网络设备盒子中引出来，研究者可以对其进行任意的编程从而实现新型的网络协议、拓扑架构而无需改动网络设备本身。该想法首先在美国的GENI研究项目中得到应用，实现了一个从主机到网络的端到端创新实验平台，HP、NEC等公司提供了GENI项目所需的支持OpenFlow的交换机设备。OpenFlow其架构见下图：

图 1.1 OpenFlow概念架构

Openflow的思路很简单，网络设备维护一个FlowTable并且只按照FlowTable进行转发，Flowtable本身的生成、维护、下发完全由外置的Controller来实现，注意这里的FlowTable并非是指IP五元组，事实上OpenFlow 1.0定义的了包括端口号、VLAN、L2/L3/L4信息的10个关键字，但是每个字段都是可以通配的，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么流表中就可以只有目的IP字段是有效的，其它全为通配。

这种控制和转发分离的架构对于L2交换设备而言，意味着MAC地址的学习由Controller来实现，V-LAN和基本的L3路由配置也由Controller下发给交换机。对于L3设备，各类IGP/EGP路由运行在Controller之上，Controller根据需要下发给相应的路由器。流表的下发可以是主动的，也可以是被动的，主动模式下，Controller将自己收集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发；被动模式是指网络设备收到一个报文没有匹配的FlowTable记录时，将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，故可以大大节省TCAM空间。当一个Controller同时控制多个交换机/路由器设备时，它们看起来就像一个大的逻辑交换机，各个交换机/路由器硬件就如同这个逻辑网络设备的远程线卡，类似的概念在Cisco的Nexus 1000/1000v、ASR9000/9000v和Juniper的Q-Fabric架构中可以看到影子，Cisco称之为nV(Network Virtualization)技术。

OpenFlow 1.0的流表分为Match Fields、计数器和指令集三个部分，Match Fields是报文匹配的输入关键字，计数器是管理所需，指令集是决定报文如何转发，最基本的转发行为包括转发给某个端口、封装改写报文后转发以及丢弃。OpenFlow 1.1增加了对MPLS以及UDP/SCTP传输层协议的支持，同时针对流表开销过大的情况设计了多级流表，并增加分组策略功能。

图 1.2 OpenFLow 1.0流表结构

图 1.3 Openflow 1.1 匹配字段结构

图 1.4 OpenFlow 1.1流水线流表结构

2 “Open”还是”Flow”

Nick同学借着GENI项目完成了OpenFlow的初始概念实验后开始向产业界推销，目前已知Arista Networks, IBM, Juniper Networks, Hewlett-Packard以及NEC等厂商在其部分交换机中支持OpenFlow协议。从其经历来看，其绝非是一个象牙塔中的单纯研究者，而是时刻和产业界保持了密切的联系。Nick 1986-1989年在HP实验室从事网络技术研究，1995年参与了Cisco的GSR12000路由器的架构设计，并且也是CrossBar的设计者之一，并且先后创建了Abrizio和Nemo System公司，后者在2005年以$12.5M卖给Cisco公司。2009年又不甘寂寞，创建了以推广OpenFlow为目标的Nicira公司，该公司是开源OpenFlow Controller NOX的维护者。

2011年3月21日，由德电、Facebook、Google、微软、Verizon、Yahoo!发起成立了Open Networking Foundation，旨在推进实现基于OpenFlow的开放网络，参与者众多，从交换芯片的博通、Broadcom到网络设备的提供者Cisco、Juniper、NSN、Force10、Ericsson、NEC以及数据中心解决方案提供者IBM、HP、VmWare、Citrix以及运营商NTT等等。网络设备提供商中阿朗、华为、中兴缺席，阿朗缺席可以理解，毕竟数据中心不是其产品方向。

除了在Datacenter中的应用外，OpenFlow的拥趸者还提出了采用OpenFlow实现网络虚拟化的架构，以支持虚拟网络运营商，其中开源的FlowVisor作为网络虚拟控制层(相当于HyperVisor)，将网络资源根据VLAN、IP分段等各种信息进行切片，分发给上层的Open Flow Controller(相当于Guest OS)进行，在各个VNO(虚拟网络运营商)的Controller上VNO可以采用脚本编程来控制其租用的虚拟网络的各种转发、QoS策略。该模式也同样适用于数据中心运营商提供VPC(Virtual Private Cloud，虚拟私有云)业务时将网络虚拟化和计算存储打包出售给租户。

虽然Nick同学忽悠了这么大的阵势，还是有很多人疑惑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将会谁是赢家？交换网络相对简单，但是L3之上各种协议散落在数十年积累的数千篇IETF RFC中，谁能够有实力实现一个如此复杂的网络操作系统而又让运营商放心呢？我想仍然可能是今天的网络设备巨头Cisco、Juniper们，产生意外的可能极小，但是产业链已经被家常，竞争的焦点已经发生了转移

从NGN引入控制承载分离架构的经验来看，没有一个领先厂家愿意开放媒体网关的控制接口，也几乎看不到商用的开放接口组网案例，因此可以推断即使OpenFlow广为业界采用，”Open”成为现实必定困难重重。如此一来Openflow能够留下的就是单厂商自己实现的控制转发分离架构以及控制器开放软件架构带来的降低开发周期、新功能快速面世能力。控制和转发分离架构在NGN带来的好处是两方面的1)对于设备供应商而言，不必为两种完全不同的能力塞在一个空间、功耗、成本均受限的一个盒子中而又保证足够的可扩展性而苦恼，两种硬件平台、软件架构可以分离发展，分别实现最优设计。2）对于运营商而言，可以获得部署上的灵活性和管理上的便利，媒体网关由于要汇聚流量，靠近用户可以节省电路资源、减少时延，控制器部署集中在更高位置，与运营商的集中管控战略一致，方便降低Opex。这些好处在Openflow架构中类似。

有人会争辩说上述好处采用集中网管也可实现，不错，所谓殊途同归，技术层面上来讲没有一种技术是不可替代的，但是产业链、经济性也就是市场是最终的评判者。如果采用网管来实现的话，实现Openflow同等的能力需要网管服务器参与到转发的在线决策中，那样网管服务的可靠性指标要提升几个数量级，并且要定义网管接口可以将未命中策略的流量引出来，那不过是另外一种形态的Openflow，就如同Cisco的nV技术一样。

3 OpenFlow对产业链的影响

如上节所述，OpenFlow隐隐约约有将网络设备市场PC化的可能，但目前尚缺一个类似于类似于微软的基于OpenFlow的网络设备操作系统提供商。理论上，运营商会喜欢网络控制接口，技术流的运营商也乐于DIY自己的网络，比如数据中心的拥有者Google、Facebook的服务器已经采用大量定制化的廉价服务器搭建自己的计算服务设备，对于网络，他们也已经开始通过ONF启动了DIY之旅。

DIY之后，网络设备价值链的核心分化，网络交换芯片，尤其是FlowTable处理器将是一个核心价值所在，控制器(也就是前述的网络操作系统)软件系统也是价值核心，有了这两个组件，大量廉价网络设备硬件将涌现在市场之上，这使得硬件市场利润摊薄。但是这种开放性将使得网络创新速度加快，尤其是当这个领域有幸诞生新的固执摩尔定律的Intel和开源Linux操作系统。

通信领域的产业周期中，创新的功能走的是一条运营商提出需求->设备供应商分析需求->标准组织标准化->设备供应商实现->运营商测试并采用的超长路径，周期以数年计算，而互联网业务提供商往往集运营商和供应商于一身，创新功能的采用从需求发现->设计->开发->上线在一个商业实体中完成，并且功能开发过程中可以不断获得用户的反馈而改进设计，这是所谓的Web业务开发的”永远是Beta版本”的概念，应用到网络设计中，运营商可以自行设计网络拓扑算法，并且可以根据网络性能统计进行迭代调整。由此可见此种OpenFlow的远景可能结果是将网络创新从供应商巨头垄断转变为运营商主导创新。

4 OpenFlow面临的技术难点

Openflow的推广除了面临上一章所述的产业博弈的问题外，目前还面临着一些技术的难点。其中之一就是路由器/交换机中广为使用的快速查找TCAM存储器成本的问题。在传统设备中，需要采用TCAM的表包括FIB、MAC、MPLS Lable和ACL表，每个表的匹配字段长度不一，分开设计，并且设计了最大容量，以期达到最小的开销。而在Openflow设备中，不再区分匹配长度短的FIB、MAC、MPLS Lable表以及较长的ACL表，一律采用最大长度的FlowTable记录代替，对于OpenFlow1.0而言，Flow table的匹配字段长度长达252比特，而一般IPV4 RIB TCAM匹配字段长度只有60-80个比特，开销增加了3倍以上，而对于路由器的线卡而言，TCAM成本占了约20-30%，功耗也占了很大一部分。因此如何减少FlowTable尺寸将是OpenFlow体系面临的一个极大问题，此外，TCAM体系下FlowTable记录的动态插入算法将更为复杂。

OpenFlow1.1设计了多级流表来减少Flowtable的开销，将流表进行特征提取，分解成多个步骤，形成流水线处理形式，从而降低总的流表记录条数，比如原始流表共有10000条，分解成先匹配VLAN+MAC，再匹配IP和传输层头部的两个独立流表，每个流表的数量可能均小于1000条，使得流表总数小于2000条。但流水线式架构使得匹配时延增加，而且流量的生成、维护算法复杂度提高，至今也未见到针对真实网络的效果评估报告。

OpenFlow的关键是通过OpenFlow将网络转发的原子操作抽象出来，并以流表来驱动流程，我们所论述的一切好处是建立在OpenFlow FlowTable能够很好地将Primitive和WorkFlow抽象，支持设计新的协议在大部分情况下的确可以通过只修改Controller的逻辑来实现这一假定上。在OpenFlow最初应用的Switch领域，OpenFlow已经有杀鸡用牛刀的嫌疑了。但是路由网络，尤其是包含有大量用户控制逻辑的边界路由器，如BRAS、无线网络的GGSN/PDSN/xGW等设备，OpenFlow需要扩展将用户控制逻辑抽象为原子操作和流程，那可能已经不适合叫FlowTable，叫AccessControlTable更合适，转发操作本身的匹配规则、转发操作中也需要增加对现存的各种接入协议和表征接入会话的协议字段的支持，比如PPPoE、GTP-U、PDP激活操作的匹配和转发封装支持。

5 结论

从需求面上讲，控制转发分离、集中控制的确可以为运营商带来好处，对设备上自身的设备软件架构也有借鉴作用，但是”Open”出来的驱动力不足，面临产业的博弈，诸多市场后进者可能会借OpenFlow博上位，但是市场既得利益者必定会持反对态度。有人会提出，我的设备本身就是控制、转发分离的架构了，我将控制功能出来就行了，没错，Cisco们看起来就是这么干的。

从具体细分市场而言，数据中心中OpenFlow处理复杂流量模型、集中管控有优势，而且随着多租户数据中心业务的广泛开展，OpenFlow所支持的网络虚拟化多租户架构、甚至可以将Controller和虚拟机管理系统进行水平交互从而实现网络和计算存储的联合调度，其带来的好处对Datacenter运营商是有一定的吸引力的。而边缘路由器的应用则是补齐网络虚拟化这个大的拼图的一部分，并且边缘路由器，尤其是无线网络的边缘路由器，需求输入仍然较多，控制转发分离架构对于加快产品创新周期、较少市场响应周期有一定的积极意义，但是其主要功能超出目前OpenFlow的范畴，需要进一步的研究

OPENFLOW是一项新出现的技术，但不是新技术。对网络中的转发行为进行集中式的控制，是通信网的长期传统，而精细化控制则是MPLS和ATM技术的强项。OPENFLOW的成功，是互联网模式的成功，或者说，是因为OPENFLOW的设计理念恰好契合互联网技术赖以生存的几个关键要素：简单、易行、低成本、开放性、兼容性。

2006年，我到合肥听美国加州大学洛杉矶分校呂松武讲授的无线网络和传感器网络龙星计划课程，对他谈到的研究之道至今记忆犹新。吕教授说，做开创性的研究，要么自底向上，通过改变底层技术引发上层变革，要么自顶向下，通过改变应用模式迫使底层技术为止变革。OPENFLOW即遵循了自底向上的原则，通过在现有的转发平面之下，增加一个更加精细和灵活的转发机制，而这种转发机制自身既没有任何控制逻辑或控制算法，也不依附于任何控制平面的技术。尽管NOX能够对所有的FLOW表实施控制，但并不排斥其他技术控制FLOW表。因此OPENFLOW只是提供了一个通用开放的转发平台，并且成功地实现了控制平面和转发平面的去耦。也许有人会认为MPLS比OPENFLOW更强大，从功能上讲确实如此，因为MPLS不仅能够在数据流的控制粒度上不逊于OPENFLOW，而且对标记的处理要比拆分包头更加快捷高效。但是，MPLS还是有些复杂，成本也是一个绕不过去的因素，而且MPLS的开放度也不够好，不像OPENFLOW那么简单直观，交换机路由器通吃且易于上手。

OPENFLOW现在已经在多种技术方案中被采纳，例如，用于构造虚拟专网、快速重路由、QOS等等，但这些仍然属于器物的层面，就好象坦克刚刚出现的时候，大部分军事强国首先想到的是把这种大杀器分散到步兵方阵中作为一个辅助兵器使用，只有古德里安高瞻远瞩，创造出坦克集群战术，撼动整个欧洲。有一句谚语，越简单的便越强大，用在OPENFLOW身上恰如其分。在路由器仍然使用转发表的情况下，控制平面和数据平面很难真正分离，因此控制平面和数据平面都很难获得真正的灵活性。而OPENFLOW打破了这一僵局，使两个平面的发展能够真正独立。这样一来，控制平面将能够容纳更加丰富多样的技术，而原有的路由器设计模式也可能被颠覆。控制平面的功能，可以附着在每个OPENFLOW交换机上，也可以集中放置在某个总控节点上，所谓的核心节点，将不再必须具备强大的计算和存储能力，只要转发能够足够即可。每个转发设备，可以同时受多个控制实体的控制，而一个控制实体，有可能在同时操纵多个转发设备的流表，而二者无需在物理上临近或关联。与此同时，一个从路由器平台上解放出来的控制平面，将更加易于扩展出更为强大的功能。例如对网络状态和行为信息的挖掘、云计算、云存储等等。更为激动人心的是，对网络的管理将有可能因此而变得更加生动和细致。我们将有可能将网络中复杂的行为用简洁绚丽的形式展现出来，同时用户也将有可能通过浏览这些直观的信息来决定自己的行为。在历史上，技术和最终用户之间的关系每拉近一小步，都会产生革命性的后果。OPENFLOW的出现，有可能成为这场革命的引信。

注：SwitchBlade: A Platform for Rapid Deployment of Network Protocols on Programmable Hardware是一篇发表于2010年SIGCOMM的文章，文中所提出的通用可编程平台的理念，有可能会影响路由设备研发的方向。和讨论特定协议或技术的文章不同，此文涉及到了“万人敌”问题，如果有机会，这个方向非常值得深入研究。

　架构组成

　　目前主要的OpenFlow解决方案包含一个三层架构，第一层架构由关键的具备OpenFlow 协议许可的以太网交换机组成。通常情况下，它们是具备OpenFlow功能的物理以太网交换机。我们还能看到一些具备OpenFlow功能的虚拟层/软件交换机和路由器。今后这类设备肯定会越来越多。

　　然后是两层服务器端软件：OpenFlow控制器和OpenFlow软件应用建立在控制器顶端。

　　控制器是一个平台，该平台向下可以直接与使用OpenFlow协议的交换机进行对话。向上，控制器可为OpenFlow软件应用提供大量功能，包括将交换机资源编入统一的网络视窗内，为应用提供协同和通用库。

　　在顶层，OpenFlow软件应用为网络执行实际控制功能，如交换与路由。应用是写在由控制器提供的统一网络视窗和通用库顶层的简单软件。因此，这些应用能够着重执行特定控制算法，并能够调整其下层的OpenFlow层以实例化网络中的算法。

　　软件架构师对这个三层的OpenFlow架构应非常熟悉。比如， Web应用服务器架构：应用在Web应用服务器顶层，而Web应用服务器又在数据库层顶层。每一个较低的层都向上提供了一个抽象概念/API以简体其上一层的设计。

　　目前，OpenFlow术语有两个意思，可以指“OpenFlow协议”，明确指称用于网络的x86指令集，也可以指“OpenFlow架构”，主要是交换机、控制器和应用层。

在多媒体化、移动化、物联网的趋势下，今日的网络规模已经远远超出了原来网络架构师的设想。旧体系所支撑的网络变得越来越复杂、速度越来越慢、成本越来越高。网络如何才能具备规模吞吐能力？能不能快速扩充？

在圣克拉拉举行的开放网络峰会上，业界给出的答案是软件定义网络和OpenFlow。在峰会上，技术业者讨论了相关的技术问题，Google、Verizon和Yahoo详细介绍了自己的项目，投资者和银行家挤满了整个会场。有两个问题吸引着大家的注意力：软件定义网络（SDN）能否重塑网络的生态体系？OpenFlow协议会不会成为网络的Android？

软件定义网络

传统的网络设备（交换机、路由器）其固件是专有化的，由设备制造商锁定和控制。而软件定义网络则让第三方软件客户端通过诸如OpenFlow这样的协议在远程访问和修改这些固件。

软件定义网络(SDN)的目标是实现理想化的企业网络，将网络控制与物理网络拓扑分离，从而创造一种从中央管理控制器向所有交换机和路由器发送流量的环境。在软件定义网络环境中，这种基于软件的控制器必须具备网络资源和容量的端到端监控能力。

OpenFlow

是一种通讯协议，使人可以在网络上访问到网络交换机或路由器的转发平面。简而言之，OpenFlow允许网络交换机之间数据包转发的路径选择由运行于多个路由器上的软件来决定。这种控制与转发的分离使得更为复杂的流量管理成为可能（传统上靠ACL访问控制和路由协议进行管理）。

OpenFlow协议将确定数据包的网络路径与物理转发行为区隔开来，从而导致了软件定义网络的诞生。并因此涌现出一批芯片批发商，导致了另一股网络硬件商品化趋势的出现。

而在峰会上，大家关注的问题是，既然SDN可以保证工程师能够快速简便地编程开发出新服务，无需关注底层的基础设施，那么是不是此类程序的编写、寻找、运行是不是也很容易？软件使能层是开放的还是封闭的？或者简而言之，OpenFlow能否成为网络的Android？增加的这层东西相当于给硬件供应商带来了一个开放系统，那么它能够为制造商带来附加价值吗？能否为应用开发商建立一个新的价值层？

仅仅因为一家公司购买了软件（或引擎）来安装可编程网络并不意味着该公司有意愿雇用有能力编程的工程师。更好的方案是购买可以运行于控制器之上的应用，或者是在控制器之上再增加一层。这个可以用现在移动领域的应用商店体系来作为类比。

按照这种类比，我们可以把控制器比作智能手机的操作系统。目前控制器有BigSwitch的Floodlight，这是开源的控制器；还有就是Nicira，使用OpenFlow协议，但基本上属于封闭的。尚不清楚未来这两家谁会一统江湖，或者不是会有新的竞争者脱颖而出。

无论如何，这场网络变革的最大受益者必将是能够为开发者带来最具吸引力平台的提供者。

“OpenFlow是软件定义网络的一个示例，”Gartner Inc.的副总裁和著名分析师Mark Fabbi说道。“这个概念已经提出10多年了。如果您了解Juniper的QFabric，它也是软件定义网络的一个实例，因为它的网络核心中也有交换机和基于结构的功能。然后，这所有的设备都与一个控制器通信，而控制器会确定路径及其所使用的服务。”

这种方法与目前的分布式且不对等控制平台的网络形成了鲜明的对比。交换机和路由器都各自维护着一些路由表或MAC地址表，其中包括相关网络因素的数据，并且它们能够根据这些数据做出传输决定。这种方法在一定程度上很有效的。但是，由于虚拟化的出现，IT基础架构比过去变得更加动态，而网络需要适应这种情况。

收集的一些openflow信息：

软件定义网络与OpenFlow商业发展

—— 面向云计算虚拟化与自动化的网络

在云计算时代，数据中心将成为我们应用和数据交付关键中心，用户从园区、远程分支点、无线和互联网不同位置访问数据与服务，连接这些服务的网络比以往来得更重要一些。云计算需要可靠的、横向扩展和高性能网络，从用户接入、互联网到数据中心。大规模部署虚拟化与云计算催生了以工作负载为中心的下一代数据中心网络，复杂的网络需要为工作负载提供端对端网络资源响应。如何应对业务快速响应需求是下一代数据中心网络人员不得不面对的挑战。以新观点来解决网络在新应用下的挑战，控制平面与转发平面分离，软件定义网络为人们提供了新思路和新方法。笔者结合实际工作经验，与大量用户交流与反馈，阅读了国内外一些书籍、互联网资料，在本文就近十网络发展、软件定义网络技术、发展趋势和商业应用等方面给出了业务挑战、技术、经济分析和解决方案，希望对读者有所启发。

云计算网络发展挑战

云计算是实现方便、快速、简单、按需访问可配置计算资源的管理模型 (部分定义来自nist)，云计算是企业IT资源管理的高级阶段，随业务变化而变化，而不仅仅是IT技术简单合并与应用。云计算所包含内容非常广泛，分成不同层次，从最接近用户的上层到最下面的物理层，包含有业务接口层、应用平台层、分布式操作系统层、虚拟化层、硬件架构层和数据中心设施层、运营商网络层，同时有支撑不同层次之间管理和平台，技术之外就作为商业模式出现的云服务交付体系和互联互通标准等。而架构即服务云计算是什么呢，很简单，就是根据用户需求，在虚拟化层、硬件层和数据中心设施基础等实现动态资源管理与调配的云计算服务，具备了这些特征计算模式就可以称之为架构即服务云。

云计算高级智能模式将使每个计算节点进化成独立反应单元，计算节点无条件反射处理由本身独立处理完成，而高级条件反射和智能分析则通过云计算高级神经中枢完成。与生物进化过程相比较，云计算进化过程类似于生物从低等到高等进化过程。目前计算资源对业务反应模式还只是处于无脊椎动物十分有限能力阶段，非常不灵活，而随着芯片技术和软件能力进阶，慢慢地计算资源调度模式就会进化到有脊椎动物高级复杂阶段。在进化过程中，计算单元单位体积内的芯片处理能力和密度每一年半翻倍提升，与此同时，起着传输神经信息的网络变得更加复杂，神经网络路径数目与计算细胞单元是几何平方匹配。

用户需求不断变化，导致网络越来越复杂

十年以来，用户数量指数增长，网络数据、流量和管理发展使得用户和网络设备不堪重负。Cisco交换机固件文件大小从原来的300K到现在的几十兆，路由器IOS软件从1998的8兆左右到现在几百兆到几个G都是常见的的事。网络设备操作系统源代码行数也增长到几百万条，越来越多的网络控制协议被加入到网络操作系统中，厂家的研发难度不断加大，用户的学习成本不断增加。尤其是控制平面的功能特性，从基本的OSPF、BGP、多播和查分服务质量保证到多协议标记交换（MPLS）、流量工程Traffic Engineering（又分为基于路由协议的流量工程如OSPF-TE和基于4层应用的流量工程如RSVP-TE）、大规模地址转换（NAT）、智能分析处理防火墙、不同形式2/3层虚拟专用网VPN、IPv6与IPv4互相混搭、移动 IP网络、用户管理认证授权和访问、记录功能等等，无数越来越多的用户要求被加入到网络交换节点里面来，以致领先网络公司都宣称自己是软件公司而不是硬件公司了。每个网络设备变成了恐龙一样的怪物，让人见而生畏。虽然在第一时间解决用户痛点和满足市场要求是我们网络供应商的责任和期望，不够遗憾的是由于网络软件控制特性与硬件集成度高，从初期协议想法到协议标准化大一般需要十年，而从标准化到规模部署又需要三到五年，导致用户需求总是被严重地推迟满足。另一方面，由于网络协议与厂家硬件系统架构高度集成，而传统网络主体架构都是封闭（尽管厂家可能使用通用商业化产品作为收发芯片），所以与之配套的软件开发和验证只能由网络厂家根据商业利益最大化决定推动，用户不得不忍受被锁定的痛苦。而用户被锁定后，基于用户最大利益创新愿望对厂家来讲就没有那么强烈了，形成了需求与研发的负反馈效应。

云计算虚拟化移动性，需要更加灵活敏捷的网络响应

根据IDC统计（图6），到2013年底虚拟机部署数量将是物理机的2.5倍，达到8千2百万台，虚拟机节省了大量的物理购买成本，但在管理复杂度上面造成运营成本增加也非常显著，比如虚拟资源脱离了物理设备相对静态信息，排错难度大大增加。虚拟交换机既要与现有虚拟管理平台兼容，又要应对高度动态变化端设备，维护虚拟逻辑抽象链接，集成与交换硬件设备功能，从移动性、机动性、维护性和集成性分类如下：

• 跟踪设备移动状态。网络端节点实体（比如虚拟机）的网络状态需要简单确定，不同主机之间可相互迁移节点状态。

• 响应网络动态变化。虚拟化环境最大特点是网络高度状态变化，跟踪虚拟机加入和离开，虚拟机往前或往后即时移动，逻辑网络环境快速变化，开放式控制平面控制流量和全局网络自动发现管理。

• 维护虚拟化逻辑标记。分布式虚拟交换机通常通过增加或管理虚拟机网络数据，来维护虚拟网络或逻辑区域上下文，这是容易理解的简单方式，需要正确和高效管理这些虚拟化标记。

• 集成操作系统和硬件。把虚拟数据转发路径设计成“卸载”模式，数据包处理由硬件芯片完成，以独立软件或硬件芯片方式实现灵活控制，增加虚拟化网络性能。

云计算网络管理方式改变——面向工作负载的网络资源调度

要全面实现新一代数据中心数据管理移动性，就需要虚拟协调角色，统一规划和部署IT智能基础架构，于是催生了工作负载为中心的IT管理模式，传统分离IT管理模式不再合适，传统IT资源分配的技术实现方式也不再合适。

工作负载是计算机所执行工作的逻辑分类，它包括谁在做工作（Who）、做什么工作（What）和如何做工作（How），它以业务观点来看工作分类，非IT技术特征。工作内容包括部分系统运行应用、用户应用连接和应用交互。工作绩效指标包括响应时间和吞吐量，也就是服务响应水平。响应时间是用户发出请求与系统响应之间的时间差。吞吐量是在一定时间内完成了多少工作。工作负载工作内容不一样，IT资源消耗重点就不一样，可以分为四类，CPU计算型、内存缓冲型、存储IOPS型或存储带宽型、网络IOPS型或网络带宽型。保证服务器、存储和网络资源统一视图，决定了以工作负载为中心的资源调度模式不但需要统一虚拟角色负责，还需要技术上对应角色平台保证。

软件定义网络介绍

一方面是控制平面与转发平面集成，越来越复杂，创新缓慢；另一方面是虚拟化资源移动性要求更加强大灵活、简单的控制平面，两者之间的差距越来越大，用户为使用网络所付出的总拥有成本越来越大。难道对于解决这两个问题用户就永遥遥无期了吗？非也，答案其实很简单，一方面，既然软、硬件绑定导致网络发展和应用缓慢，那么我们就把它们分开来，各自相对灵活独立发展，开发实现基于标准硬件平台的灵活简单的控制平面。另一方面，云计算和虚拟化需要极大的网络扩展性要求，当前网络转发平面与控制平面都需要横向扩展和极大性能增强，大家平行分离，而扩展模式下控制平面的控制信息本身流量有限并可预计，所以人们就不需要昂贵的专门高性能转发芯片处理控制信息，那么经济性解决方案就是控制平面由独立可扩展软件实现。同样一个方法，解决两个大问题！于是一群先行者就开始软件控制独立与网络转发平面之旅，我们称之为软件定义网络。

什么是软件定义网络？

软件定义网络，又有人称为可编程网络，就是将网络设备配置平面从嵌入式节点独立出来到软件平台，由软件驱动的中央控制节点自动化控制的网络架构。软件定义网络以开放软件模式替代传统基于嵌入系统的、不够灵活的控制平面。软件定义网络是新的网络控制平面实现方法，它适应了降低网络复杂度、虚拟化和云计算的网络需求。它的发展是对传统网络厂家封闭专有控制平面技术产生了的破坏性创新，将对网络厂家变革导致巨大推力和影响。控制平面和转发平面分离，转发平面特性减少，专注而简单，减少了设备硬件从而减少了资本性支出（Capex），运营性支出 Opex减少原因是集中的、横向扩展和自动化简化了网络运行管理，减少人工支出。

图1 软件定义网络示意图

软件定义网络实际上核心技术本身并没有什么创新，传统交换或路由设备也都有独立转发平面或强大控制平面，只不过传统模式转发平面是通过在同一个机箱的不同接口模块去完成，控制平面由机箱的路由交换控制模块完成，缺点当然是开放性不够、及时响应动态变化能力有限，原因是比如设备无法做到第三方编程自动化集成，每个设备需要单独维护自己的地址表，有限CPU和内存却需要全网实时计算和动态处理。传统网络每个设备有点智能，但是非常有限，它们只能根据本节点进出数据流做出被动响应，无法知道其他节点动态状况。各个网络节点离散式自我控制，只见个别树木或树叶，没有大家统一协调的控制平面，不见整个网络森林，所以对整个网络来讲，尽管实现了动态路由协议，其架构基本是静态的。传统网络所谓动态调度实现基础也就是二层和三层的实现链路资源动态分配，而对于四到七层与二三层是否匹配和谐而调度，则心有余而力不足。即便有折中解决方案，也只是需要处在固定位置的昂贵负载均衡或安全设备协助完成。

理想的软件定义网络模式下，独立的离散式智能从分支节点上收到中央控制节点，中央枢纽保持全网流量监视和控制，从OSI 2层到7层实时把握网络整体状况，即时控制和调度，建立强大中央智能，对全网和100%垂直完整做出有效反应。在软件定义网络环境下，中央控制节点可以根据相应算法、逻辑、分析和规则，以软件定义规范方式将配置信息推到交换和路由节点，完成路由或交换从中央控制节点接受特定格式指令规则过程，交换和路由节点更新数据转发平面落地规则，完成数据转发。中央控制节点针对每个细分的网络路径，按照一条条“信息流”细分，每个“信息流”数据落地转发由每个特定交换或路由节点完成。当计算或存储资源变化时，中央控制节点根据分析结果重新调整节点配置规则，这样就实现虚拟化和云计算网络所需要的自动化和精细化动态配置管理。

常见专有软件定义网络

软件定义网络——vSphere之VNetwork体系架构

VMware vShpere可以通过虚拟化交换机控制平面管理VLAN、QoS策略和ACL，vNetwork API提供了标准接口，网络厂家根据接口开发与专有固件互动功能。网络厂家在虚拟化控制台安装控制插件，当虚拟机移动或变化时，对应指令从vSphere API上层发出，插件被调用，指挥网络节点调度物理交换资源，自然而然vShpere成为了虚拟化交换网络的控制平面代理。Cisco Nexus 1000v就是一种基于VMware体系架构的专用实现，它不但兼容了VSphere标准API，而且提供了标准Cisco IOS命令行方式。

图2 vSphere的软件定义网络架构

Dell Force10新一代数据中心架构支持虚拟化感知软件定义网络。Dell Force10边缘交换机FTOS可以安装虚拟管理器插件到虚拟操作系统包括VMware和Citrix，当虚拟控制平台移动虚拟机时，通知插件以Hyperlink方式在目的交换机FTOS上运行配置脚本，自动配置与虚拟机所匹配的网络资源，而后移动虚拟机。

图3 Dell Force10 集成自动化及虚拟感知网络架构来源：www.force10networks.com

软件定义网络——无线局域网

其实无线网络控制器与无线接入点组成的无线网络某种程度上也算软件定义网络应用。以戴尔公司PowerConnect-W无线解决方案为例，无线接入点AP92/93系列提供无线接入转发平面，无线控制器W650系列实现同一用户认证，基于用户服务质量服务定义，集中管理加密信息，控制器分发控制策略到转发平面接入点，控制器与接入点之间信息加密传输，组成完整、安全和可定义的无线网络。

图4 无线网络软件定义架构

软件定义网络——Juniper QFabric

Juniper定义了专有的下一代网络基础架构QFabric。QFabric是全新数据转发平面和控制平面交换体系架构，从边缘交换到核心交换都采用了新型交换架构，支持大规模节点接入。数据转发平面有QF/Interconnect核心节点、QF/Node作为边缘节点，控制平面由QF/Director组成。控制平面QF/Director由冗余x86物理服务器集群组成，通过双千兆链接控制每个网络节点，控制链路独立于数据转发平面链路，控制平面节点就是我们说软件定义网络的中央控制节点。

图5 瞻博QFabric系统架构图来源：www.juniper.com

OpenFlow软件定义网络与应用

开源软件定义网络OpenFlow架构

Open Networking Foundation （ONF）开放式网络基金会今年成立以来，OpenFlow规范得到主流网络厂家追捧，尤其是最近在Las Vegas Interop 2011举行网络大会，OpenFlow大出风头。究其原因，其背后基本理念是软件定义网络（Software-Defined Network）。OpenFlow规范实际上是一整套软件应用程序接口，控制网络数据如何转发，可基于硬件实现，OpenFlow增加了定制转发数据的控制程度，减少了支撑复杂控制所需的硬件成本。OpenFlow网络控制节点可以通过规范与支持OpenFlow的交换节点沟通配置信息，决定数据转发平面的转发表，控制器与转发节点间通过SSL加密传输。OpenFlow支持定义的“信息流”主要是从1层到4层的关键信息包括端口号、VLAN、MAC、以太网包头、IP地址、 IP协议号、TCP端口号等。配置信息通常包括“信息流”和与之对于的动作。每个“信息流”有符合某种特征的数据包及动作组成，比如源IP/源Port，目的IP/目的Port，5种不同转发动作。

图6 OpenFLow的架构图

图7 OpenFlow“信息流”定义

用户可以通过OpenFlow预设通用规则，每种不同网络节点可以根据设备特点更新转发平面规则，比如转发交换机更新MAC地址转发表、VLAN端口转发表、1到4层转发表，路由器修改访问控制IP列表，防火墙修改进出端口规则等。

图8 不同网络节点应用不同网络“信息流”规则

OpenFlow它增加了网络灵活控制能力，分布式节点智能通过OpenFlow指令得以实现，外部OpenFlow控制管理节点的实时控制，集中统一中央智能。OpenFlow根据运行实况实时控制分布式节点，分布式节点生成快速转发表，无须进行复杂智能分析计算，只要执行网络转发平面功能。当新转发节点加入到OpenFlow网络时，自动从中央控制节点得的最新网络配置信息，完成网络自动化感知。而中央控制节点基于x86标准服务器架构，强大计算能力和横向扩展特性保证了控制平面扩展性和经济性。

OpenFlow独立控制平面出现，TRILL或Shortest Path Bridging协议变得不是那么重要，因为OpenFlow控制器可以拥有有全网视图，所以动态防止环路发生。OpenFlow不但增加了传统转发平面的效率，在提供高级网络服务方面还可以展现独特价值，比如多对一的网络虚拟化，分布式负载均衡和分布式防火墙或入侵检测，非常不同于传统模式的一对多网络虚拟化模式。每一类分布式网络资源服务与单独云租户对应，每个云租户都有独立的跨物理节点的虚拟化网络，比如不同虚拟端口交换机，对租户管理员来物理网络端口透明，逻辑化网络派生于在物理网络资源上抽象出的网络虚拟资源池。虚拟机移动后，当虚拟机相应“信息流”的第一个数据包到达移动后的本地交换机节点，如果本地交换机节点没有发现匹配的转发规则，整个数据报文会被送到中央管理节点，中央管理节点根据定义规则逻辑设定本地规则，并应用到本地交换机的转发表建立新的匹配项，之后的“信息流”不再通过管理节点，由转发节点直接完成。

OpenFlow在虚拟化软件交换机Open vSwitch应用

Open vSwitch是多层虚拟化软件交换机，它遵循Apache 2.0开源代码版权协议，可用于生产环境，支持跨物理服务器分布式管理、扩展编程、大规模网络自动化和标准化接口，实现了和大多数商业闭源交换机功能类似的软件交换机。 OpenSwitch分离快速数据转发平面，OpenFlow作为新型控制平面，不同物理主机的虚拟化交换机通过OpenFlow控制，集群组成分布式虚拟化交换机，还可以实现不同租户虚拟机和虚拟网络隔离。正是由于Open vSwitch对OpenFlow支持，推动了OpenFlow在开源虚拟化领域的应用和发展。

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

软件定义网络OpenFlow在超大规模Web 2.0 网络应用

Web 2.0用户如Google、Facebook的服务器台数近百万台，单数据中心服务器数目也超过十万台，国内公司如Tencent、Aliababa和Baidu安装服务器数估计也超过数十万台。在这些超大规模服务器群的网络设计与实现尤为重要，稳定、可靠和高性能的网络是Web 2.0业务的生命线。一方面在核心层实现高可靠性和高性能，另一方面是大量的服务器接入需要内网、外网和管理网接口，3倍以上端口数目，大量接入层设备成本成为是基础架构成本的重要组成。为了进一步降低服务器成本，集中、整合与开源虚拟化是下一代Web 2.0架构的发展趋势，单一数据中心虚拟机数目将部署到上十万台，这种环境下的公共云虚拟化移动性比我们之前说私有云移动性来得技术更加复杂、管理更加困难，传统网络厂家设备非常难以满足超大规模的“信息流”要求。

从传统网络架构迁移到软件定义网络将是一个艰难的旅程。网络技术应用演变过程有两种方式，一种是先边缘后核心，另外一种是先中心后边缘，不过从客户心理学来看，先边缘后核心是更容易接受的应用方式，所以我们可以预计OpenFlow应用过程也将是从边缘到核心的应用过程。具体方式是用户在接入层采用支持OpenFlow交换机，建立独立管理网，安装独立开发的或商用控制平台软件，测试和完善控制平台软件，从类OpenFlow交换机采集数据流量模式和优化定义规则，并同时至顶向下从应用角度分析，两种分析方式结合抽象出网络数据模型，这就是软件定义网络的规则基础，从是什么推进到应该是什么，再到如何是什么。

目前主流交换机厂家都还没有推出OpenFlow交换机，NEC公司是第一个推出支持OpenFlow交换机的公司，产品型号是PF5240，带有48个千兆和4个万兆上联端口，NEC还开发了OpenFlow控制器软件支持PF5240或其它第三方OpenFlow兼容交换机。

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

如上图所示，OpenFlow在数据中心网络里建立从一台虚拟机到另外一台虚拟机的转发路径，虚拟机与虚拟机之间的三层网络基础上建立了二层广播域——虚拟以太网交换机，OpenFlow扩展了三层相对静态功能，根据数据流动态建立负载均衡决策路径，并依据虚拟化交换网络配置改变最优化的转发路径，从而简化了大型数据中心3层网络适应2层虚拟机移动性要求。

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

在传统电信运营商网络里，IP层网络和传输网络独立分离的，它们分别单独管理，IP网和传输网之间没有交互，IP链路静态配置，传输层电路或放大器也是静态的，导致不同层次功能和资源重复，增加用户采购成本和运营成本负担。传统网络电路交换更无法自动感知报文交换要求，自动化控制平面操作，只是被动地依赖网管平台手工操作，服务交付时间长达几天，运营商只能是成为网络带宽销售者。尤其在云计算环境下，需要跨越数据中心的资源管理，需要上层资源与物理链路层调度的匹配与自动化，每个租户在数据中心之外需要建立虚拟网络服务和实现自助管理。这样用户趋势就是报文交换网络与电路交换网络融合，在同一平台下管理和运维，报文交换和电路交换之间互动，实现不同层次间动态调度。但是问题是报文和电路融合非常困难，因为IP网络和传输网络架构非常不一样，整合运维非常困难，传输网络保持不变，结果会造成融合更加膨胀，最后导致网络不可用，所以有专家说了架构融合才是真正融合。哪什么才是最佳控制和管理方式呢？可不可以基于1层到4层建立 “信息流”的控制方式呢？可以，解决思路是按光纤、放大器、时隙和报文内容细分，从电路交换和报文交换抽象映射到2到4层信息流交换层，实现基于广域网的网络虚拟化。斯坦福大学的有关专家正在积极研究将报文交换和电路交换集成,，合并起来统一抽象并管理和控制，实现基于“信息流”网络服务架构，基于不同流量和应用模型建立端对端网络虚拟化，这些研究为OpenFlow在运营商网络应用提供无限的可能性。

图10 运营商基于”流”统一控制管理网络

软件定义网络发展挑战

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

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

第二点，OpenFlow成熟度问题，目前OpenFlow还只应用于科学实验和校园内部网。没有大规模产品化，量产之前的成本优势还是很大疑问。网络供应商选择不多，没有供应商与供应商横向比较，企业难以通过市场竞争方式获取新技术并最优成本的产品。除了转发节点成熟度问题外，因为目前并没有商业化的控制平台，如何实现控制节点软件开发、如何维护升级也是大问题。OpenFlow产业的先行者还需要对企业用户进行更多初期普及、培育、培训工作，帮助他们了解、测试和小规模测试软件定义网络新技术产品。

第三点，和大多数开源项目一样，目前OpenFlow等项目无法像商业解决方案一样有独立的商业机构为客户提供专业从咨询、、分析、设计、部署和运维管理服务，保证客户网络与IT系统运行。用户需要更多更高水平的有经验的网络维护人员，非一站式解决方案将导致学习成本比较高昂。尽管很多大公司参与OpenFlow项目，但是开发驱动力和技术支持主要来自社区自由软件编程人员。所以成熟的闭源软件定义网络将继续在普通企业应用尤其是私有云起主导作用。

第四点，软件定义网络天生的安全风险问题。集中智能虽然可以给运营管理带来全网视图和优化，以简化管理提高效率的好处，但是也带来而外的管理风险，中央中枢如果损坏或被黑客侵入怎么办？（基于x86软件系统显然比私有嵌入架构容易受到黑客攻击，尤其是开源社区提供丰富源代码），结果会导致全网瘫痪或变成僵尸网络，变成又聋又哑或失去控制的庞大网络怪物？网络攻击将从单点网络节点直接上升为集中网络控制器，后果将更加严重。

作者简介

李海平，邮件：haipingli@139.co，新浪微博”行云流水万泉河”，近20年IT行业市场和管理经验，清华大学毕业，香港科技大学MBA，CCIE#4435 (R&S、SNA/IP)，热衷研究应用经济学、商业管理和IT产业发展，在IT商业分析、IT与业务整合、云计算、应用架构、虚拟化、服务器、网络和存储业务拓展及管理等方面有多年经验。担任国际分布式管理任务工程组会员(DMTF)、国际存储工业协会会员(SNIA)、外设组件互联组织会员(PCI-SIG)和串行ATA国际组织会员(SATA)。目前负责Dell大中华区下一代数据中心刀片服务器与网络业务，积极推动中国客户发展新兴技术，应用戴尔全球客户最佳实践。

虽然OpenFlow网络在最近几个月一直是宣传的热点，甚至还在Las Vegas的Interop 2011上享受到明星般追捧，但它是一个协议概念——软件定义网络——有可能使虚拟化和云网络实现真正的变革。

在一个由软件定义的网络中，交换机和路由器采用了一些集中软件管理元素方式的某种形式。在OpenFlow的环境中，控制平台是从数据转发平台分离出来的。一个集中的控制器维护着网络的实时，整体的情况，将网络路径定义为“流”，并将这个数据流分发到各个交换机和路由器上。通过这些流，控制器可以协调所有网络设备间的数据传输，从而在虚拟环境和云网络中实现所需要的自动化和细致动态分配管理。

OpenFlow和软件定义网络：整合OSI协议层

OpenFlow和软件定义网络的一个主要目标是：使网络更好地响应和适应其他IT基础架构。目前的网络是静态的。虽然它们关注于OSI模式的2层和3层协议，但是这种模式并不支持服务器虚拟化。

“之前，网络人们关心的总是关于数据包。这真的就是与数据包有关的吗？网络只考虑2层和3层协议，但是事实上所有的OSI协议层都必须更好地整合才能了解网络状况，”Forrester Research高级研究分析师Andre Kindness说道。

虚拟化已经使IT基础架构变得更加动态，因此网络必须响应这种改变。当服务器管理员将一台服务器上的虚拟机迁移到另外一台服务器时，网络必须能够自动地调整VLAN、QoS政策和ACL。

“目前，迁移一台虚拟机一般会花费2天的时间，这是因为它不是自动化的，”Kindness说道。“它可以在服务器中实现自动化，但是一旦涉及网络，如果需要修改网络，那么网络工程师必须在VM迁移之前先修改好这部分网络。”

基本上，网络与应用程序还是分离的，网络还仅限于管理数据包，Kindness说道。软件定义网络就是要“提高服务器和网络的效率，并尝试将它们整合在一起。它会观察各种类型硬件的工作负载，然后决定数据包的流向。它关注于整体效率，并尽可能以最佳方式利用资源，”他说道。

软件定义网络：如何实现？

OpenFlow并非是软件定义网络的唯一实现方式。Arista Networks与VMware一起合作创建了具备自己风格的软件定义网络，这种网络更善于响应虚拟化服务器基础架构的变化。通过向VMware开放它的交换固件，Arista的交换机可以自动适应新虚拟机的初始化或在基础架构中迁移虚拟机。

“我们一直在做致力于Open vSwitch与我们的交换OS整合到一起的内部开发，”Arista的市场副总裁Doug Gourlay说道。“我们所做的工作就是将诸如vSphere的设备变成网络控制器。当您使用vSphere时，它可以控制VLAN、QoS政策和ACL，所有这些操作都必定是在虚拟机中进行的。我们说服自己，对于我们的网络设备可以实现一些部分，我们将采用vSphere。当您在vCenter中创建一个虚拟机和当您需要迁移该虚拟机时，对于网络所需要做的一切，我们都可以通过一个在我们交换机和vSphere之间定义和规定的API自动实现。”

正如之前所提到的，Juniper的QFabric架构在某种程度上是一个软件定义网络，但是这个架构现在还未实现。Juniper已经发布了QFabric的数据转发设备，即QFX3500，但是类似于软件定义网络控制器的QF/Interconnect核心设备和管理装置QF/Director只有到今年年底才会发布。

虽然基于OpenFlow的产品市场正处于发展初期，但是OpenFlow架构的开放方式与Juniper的架构是截然相反的。使用QFabric来建立一个软件定义网络需要使用所有的QFabric产品。而使用OpenFlow建立一个软件定义网络，则只需要使用任意供应商的一个支持OpenFlow的OpenFlow控制器和交换机。

目前仍然没有任何主流网络供应商发布支持OpenFlow的交换机产品，虽然今年在Interop上许多供应商演示了这个技术。NEC Corp.是第一个发布这种产品的供应商。NEC是一个主要专注于日本本国市场的网络供应商，它已经与大学研究者合作一起进行了5年的OpenFlow支持研发。这项工作随着在Interop上发布NEC的可编程流（ProgrammableFlow）生产线而达到顶峰。该产品在展会中获得了Interop最佳产品称号。

NEC的可编程流（ProgrammableFlow）目前由2个主要产品组成。第一个是支持OpenFlow的交换机PF5240，它有48个Gigabit Ethernet (GbE)端口和4个10 GbE上行链路端口。第二个是可编程流控制器（ProgrammableFlow Controller PFC）—这是一个OpenFlow控制器软件，它可以为PF5240交换机和将来任何支持OpenFlow的第三方交换机确定转发路径。

有几个新兴的公司也正在秘密研发OpenFlow控制器，并与交换机供应商建立合作关系。其中包括Big Switch Networks和Nicira Networks。

OpenFlow架构是生成树的一种替代方法吗？

根据Big Switch Networks的共同创办人和市场销售部副总经理Kyle Forster的看法，基于OpenFlow的软件定义网络不仅仅能够适应虚拟化所带来的变化。通过将交换机和路由器的控制转移到一个集中控制器上，OpenFlow也支持高级多路径转发技术。这意味着，企业可以在OpenFlow控制器上定义多路径流，而不需要使用TRILL 或最短路径桥接协议（Shortest Path Bridging）来避免生成树协议带来的限制。由于控制器掌握完整的网络结构，因此它可以防止循环发生。

Forster 说道，OpenFlow控制器还还在网络上实现了可编程性。通过在控制器上开放API，第三方可以开发一些软件，这些软件使用OpenFlow控制器在网络上运行高级网络功能和服务。例如，有一些研究人员已经在OpenFlow控制器之上开发了负载均衡器。Forster表示，安全供应商可以开发虚拟分布式防火墙或入侵防御软件，它们通过在OpenFlow控制器上定义的流，而在每台交换机和路由器上施加安全政策。

Big Switch Networks正在开发一种软件，它允许网络工程师在他们的基础架构之上建立一个多租赁模式的软件，这特别适用于云计算环境。工程师可以使用Big Switch的控制器创建一个使用多个物理交换机端口的虚拟交换机，并将它作为一个服务于服务器和应用程序的固定网络呈现给系统管理员。

“我们的Interop演示展示了这个架构视图，您可以使用来自不同交换机的端口，比如一台交换的2个端口，另一台的5个端口，第三台的7个端口，并将所有端口整合到一台大型虚拟交换机上，”Forster说道。“管理员可以登录这个虚拟交换机，然后他们所看到的是一个具有14端口的交换机。但他们不知道这些端口是来自数据中心多个不同设备。一方面，管理员会感觉他们是拥有一个完整的物理交换机，但是事实上我们是把交换机放在不同的物理硬件上，并且隔离它们，这样如果管理员做了什么毁坏虚拟交换机的事，该虚拟机所依赖的硬件仍能够保持正常工作。”

Gartner's Fabbi说道，虽然OpenFlow有大好前景，但是在这些供应商开始发布和销售产品之前，这个协议实际上还只是一个“研究项目”。市场上已经好几年少有新产品出现了，更不用说完整的生态系统。目前，OpenFlow供应商正关注于云计算供应商，因为他们是最需要软件定义网络功能的。但是可扩展性仍然是一个问题。

和无线LAN架构中很重要的控制器一样，OpenFlow控制器可能会遇到瓶颈，因为交换机和路由器会将转发决定授权给一个运行在服务器上的控制器。

“老实说，我不认为这是可行的，”Arista's Gourlay说道。“Stanford的最大产品OpenFlow网络流量的设计速度是每秒500个流。我们必须在几秒钟内处理上百万个流的网络。我不确定它是否已经能够扩展到这个水平。”

然而，OpenFlow供应商都深知可扩展性问题的重要。Forster表示，BigSwitch正在为它的控制器开发集群技术。它不是在开发一个能够处理大型网络上所有流量的大型控制器。相反，它正在开发能够以协作方式管理网络的控制器。

OpenFlow控制器也将继续由交换机和路由器自己来决定转发路径。事实上，它们就应该负责这部分工作。Forster表示，在OpenFlow架构中的交换机不会是非智能设备。相反，它们必须更健壮且能够更好地运行大量OpenFlow规则，并支持其它OpenFlow应用程序。他指出了基于控制器的无线LAN架构的接入端可以如何变得更健壮的，从而支持诸如流氓软件检测和频段管理等应用程序。

此外，很多OpenFlow交换机本身将负责大量转发决定，只有收到意外的数据包流量时，它们才需要在控制器上查找指令。

“交换机可以根据OpenFlow控制器上基于流的规则来转发数据包，”NEC Corp.的业务开发总监Don Clark说道。“在我们面临很多虚拟机移动性和很多网络变化的情况下，我们会相应地进行处理。当一个不符合本地交换机现有规则的数据包到达时，第一个数据包会转发给控制器。它会按逻辑进行处理，然后控制器会在流表中设置新的规则。”

在最近几周，随着Open Networking Foundation(ONF)的启用和几乎所有主流网络供应商宣布对规范的支持，OpenFlow规范在网络领域中暴发了。事实上，OpenFlow交换机在Interop Las Vegas 2011上就已经公诸于众了，并且也引起了很大的争论。

SDN允许网络工程师控制和管理他们的网络，以便最好地服务他们各自需求，从而增加网络功能和降低运营网络的成本。Open Networking Foundation支持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将配置下载到网络设备中。因此，当控制器评估和重新平衡配置时，网络就可能动态地进行重新配置。这就是所谓的软件定义网络。

各供应商将如何使用OpenFlow？

在Interop 2011展会上就有众多厂商在推广自己的OpenFlow交换机和控制器，其火爆程度自然不言而喻了，那么是所有的供应商都在积极响应吗？本文分析了HP Networking，Cisco等供应商将如何使用OpenFlow。

HP Networking: HP已经在OpenFlow上投入了大量的资源。我见过HP向委员会提交的一个QoS功能的演示，并且公司也为控制器平台制定了全面的软件计划。

NEC: 您可能还未听说过NEC也是一个网络供应商，但是这家公司有完整的产品系列，并且已经在NEC美国市场开始销售了。NEC已经为OpenFlow做出了几个重大的贡献，而且它有一个支持OpenFlow的完整系列交换机。在Interop上，NEC演示了它的OpenFlow控制器。

Cisco: 虽然网络巨头是Open Networking Foundation的成员之一，但是我还未能找到它关于OpenFlow的计划。很可能Cisco会觉得OpenFlow破坏了作为营利产品的IOS 软件。OpenFlow最突出的优点是减少硬件交换机的成本，而本身不会给网络供应商的销售带来任何的提升。

Avaya: 虽然公司在Shortest Path Bridging策略方面下了很大的功夫，但是据我了解，公司目前并没有任何关于OpenFlow的计划。

Arista: 网络新贵并没有任何关于OpenFlow的发布计划，同时它还指出在一台设备上管理所有流是不可能的。虽然Cisco也这样认为，但是我认为这是对OpenFlow工作方式的一种误解。使用OpenFlow来处理每一个流是可能的，但这并不是必要的，这只是一个配置选项。

Big Switch Networks: 这个最近成立的新兴公司关注于OpenFlow解决方案，特别是网络虚拟化。虽然Big Switch网站上没有任何的详细信息，但是我认为它们正在开发控制器和交换机。

如果OpenFlow能够拥有足够多的客户，那么它将从根本上改变网络行业，因为我们目前所使用的控制协议（例如OSPF或者Spanning Tree或者DCB）将被软件控制器所取代。虽然这会促成硬件的商品化，但是软件控制器将成为网络行业中新的组成部分。软件的功能、特性和可靠性将是决定OpenFlow成功与否的关键所在。

这个软件在我的网络上到底在做什么？

如果要说在Interop展会中我与各位嘉宾之间的交谈要有个总主题的话，那便是软件是网络的未来。可以说，一直以来都是这样，即使最佳的交换机机架中，也是代码驱动它的运行。直到今年，OpenFlow规范——几个月之前它还只是斯坦福大学的一个研究项目——现在可是极大的热点，大多数网络供应商都争相宣布他们的软件定义网络的策略，或者迫于舆论而紧紧跟随。

即使没有网络虚拟化，只有软件的网络设备已经从一种开发/测试环境的方法转换为支持生产环境的产品了，这是很明显的一点。在Interop 2011上，我所交谈过的每个供应商都在宣传他们的硬件设备的虚拟化版本。例如，Infoblox谈到了虚拟IP地址管理和配置管理产品，而BlueCoat则谈到了虚拟化WAN优化和安全设备。

基于云的网络管理——基本上是由软件驱动的——也在Interop展会上有所涉及到。例如，PowerCloud在会场上介绍了它的技术是如何支持OEM伙伴实现基于云的无线接入点管理的。这样一来，管理服务供应商就可以与诸如Aerohive 和 Meraki的公司展开正面竞争。通过将很少的代码添加到他们的固件中，接入点就能够“呼叫”主机服务，然后通过唯一的识别码连接到特定的客户。在很多方面，基于云的管理不需要与大型WLAN硬件解决方案相当的资本支出就能够向SMB市场提供企业级的特性和功能。

Cisco在Interop展会上也加入了云管理WLAN的讨论，它介绍了自己的新系统。该新系统可以让企业通过一个集中私有云对成千上万的分公司的AP进行管理。在硬件主导的时代转换到软件是一个逻辑方法，由于虚拟化时代的灵活性水平要求将成为硬件的唯一挑战。它未来的发展值得我们期待。

OpenFlow规范随着ONF的启用和几乎所有主流网络供应商宣布对规范的支持，在网络领域中暴发了。本文主要分析HP Networking，Cisco等供应商将如何使用OpenFlow。

在Interop 2011展会上就有众多厂商在推广自己的OpenFlow交换机和控制器，其火爆程度自然不言而喻了，那么是所有的供应商都在积极响应吗?本文分析了HP Networking，Cisco等供应商将如何使用OpenFlow。

HP Networking: HP已经在OpenFlow上投入了大量的资源。我见过HP向委员会提交的一个QoS功能的演示，并且公司也为控制器平台制定了全面的软件计划。

Avaya: 虽然公司在Shortest Path Bridging策略方面下了很大的功夫，但是据我了解，公司目前并没有任何关于OpenFlow的计划。

OpenFlow如果能够拥有足够多的客户，那么它将从根本上改变网络行业，因为我们目前所使用的控制协议(例如OSPF或者Spanning Tree或者DCB)将被软件控制器所取代。虽然这会促成硬件的商品化，但是软件控制器将成为网络行业中新的组成部分。软件的功能、特性和可靠性将是决定OpenFlow成功与否的关键所在。

这个软件在我的网络上到底在做什么？

Cisco在Interop展会上也加入了云管理WLAN的讨论，它介绍了自己的新系统。该新系统可以让企业通过一个集中私有云对成千上万的分公司的AP进行管理。在硬件主导的时代转换到软件是一个逻辑方法，由于虚拟化时代的灵活性水平要求将成为硬件的唯一挑战。它未来的发展值得我们期待

如果最近几周您不是在毫无电子信号的遗忘小岛的话，那么您可能已经注意到围绕最新网络互连技术OpenFlow的铺天盖地宣传了。很显然，网络行业是非常需要下一个热门事件的出现。上一次我看到类似的事情是在2000年初，当时MPLS被认为可以解决所有预期的网络互连问题。在那时，宣传的力度非常大，还有人专门还撰写了一个描述MPLS用作电流传输的愚人节RFC。

类似于MPLS，OpenFlow并不能带来世界和平、治愈癌症或发现外星人。然而，它在改变网络互连环境格式的方式可能与Unix和Linux改变操作系统格局的方式相同，是通过在一个分布式交换架构中实现一种配置转换表的标准方法。

但是，这并不是在Interop展会上OpenFlow发布激增的主要原因。总之，OpenFlow在几个月之前还只是一个不知名的研究产品。事实上，供应商发布一个概念验证代码的速度也表明了OpenFlow本身的一个缺点：它只是一个简单的低级别API（有些人将它比作BIOS）。实践中最难的工作是写出人们热议的控制器软件。这不是件容易的事情。网络供应商在类似领域已经投入了大量的人力。因此，那些希望创新的新控制器应用程序腾空出世的人可能也相信有牙仙子和独角兽眼泪的传说吧。

到目前为止，我所听到的一个最极比喻是将OpenFlow比作一个C编译器。我们现在不使用现有的应用程序，而是有能力开发自己的应用程序了。这可能是真的，但是有人仍然必须开发这些应用程序，测试它们，并且保证它们的规模，这是OpenFlow必须解决的最大问题之一。同时，虽然供应商已经对控制器应用程序进行了“神化”宣传，但是我仍然不会期望出现奇迹。作为技术专家和教授的Scott Shenker解释道：“OpenFlow不可能让您实现一些以前在网络中无法实现的事情。”

而且，即使OpenFlow能够与C编译器相提并论，但是我们并没有看到仅仅因为出现了一个C编译器就会引起数据库程序包或者电子表格程序的大爆发。少数供应商在每个应用程序领域占据主要的市场，而OpenFlow控制器的格局在这几年都非常相似。很可能有少数制造商会基于通用商业芯片生产硬件产品，也有少数软件供应商（可能包括Cisco、Juniper和VMware）会生产大多数控制器节点产品。假如您仍然相信OpenFlow会降低价格和压缩某些网络互连公司利润空间，那请您先看看Oracle的财务报表吧。

继融合增强以太网、TRILL、SPB之后，OpenFlow无疑是近几个月来网络界最大的热点。关于OpenFlow的文章报道见诸于近期国内外各大IT媒体和专业网站，在Interop大展上还有专门为OpenFlow开设的实验区。不过其间对OpenFlow这股热情泼冷水的也不少，甚至怀疑这是不是又一场为了博眼球的公关炒作。

OpenFlow并非突然而至，它的研究始于2007年，起源于斯坦福大学的研究项目，目的是重新设计互联网。在2008年的全球网络创新环境工程大会上，有一场OpenFlow的展示。在演示中，研究人员利用连接加利福尼亚和日本的实验网络，演示了OpenFlow的新功能。两个国家的玩家进行了一场电脑游戏，OpenFlow被用来在网络上定位一台虚拟服务器，以便最大幅度地减少每个玩家所感觉到的平均延迟时间。当时OpenFlow技术目前尚处于概念验证阶段。

OpenFlow采取软件定义网络的方式，也就是说用户可以忽略底层硬件的具体情况，直接对流量进行定义并设置流量经由何种方式通过网络。目前OpenFlow已经取得了众多网络软硬件厂商和运营商的支持，既有许多赫赫有名的公司如思科、博科、瞻博、惠普等，也有新兴企业如Big Switch。但是各家厂商对于OpenFlow的积极性还是不相同的。就拿这次Interop专门设立的OpenFlow实验区展示来说，共有15家厂商参与，但思科不在其中。另外还有一些厂商和专家也表示持怀疑态度。

而博科则是OpenFlow的大力推动者之一，博科服务提供商产品副总裁Ken Cheng在交流中就明确表示，OpenFlow非常适合超大规模的数据中心解决方案，Google、Facebook、德国电信、Yahoo和Verizon等都已经在开发OpenFlow应用，中国的腾迅也非常感兴趣。

OpenFlow可以将对流量如何通过网络的控制权从交换机和路由器交还给网络拥有者或者应用。它要求用户负责精心制定路径策略，去发现可用带宽、减少堵塞，以及最优转发路径。这就牵涉到用户需要有足够的软件开发力量，才能完成相关的工作。目前，对于拥有强大技术团队的运营商和服务提供商来说，这基本不是问题。但对于一般企业来讲，还是有一定难度的。

目前OpenFlow还并不完善，尚存在许多问题待解决，而且涉及的面非常广。要想实现软件定义的互联网，还需要得到业界全方位的支持和努力才能梦想成真。好消息是今年三月刚刚成立的开放网络基金会正在推动OpenFlow标准规范的制定。

一些数据中心的技术，例如扁平化2-3层网络架构和虚拟设备等目前都还处在研发和部署的早期阶段。我认为，其中的每一种技术都还在各自的演进过程中，但我敢说，一旦它们联合起来共同实施的话，结果将是革命性的。

为何我如此看好这些技术？因为扁平化2-3层网络架构承诺了网络中任意两点间的低延迟连接，这将从根本上改变数据中心网络的设计。换句话说，我们不再是把4-7层服务带给网络，而是把网络带给4-7层服务。想要给某个应用增加防火墙或者应用负载均衡吗?那只需简单地改变网络配置，增加几个VLAN标志就行了。如果利用OpenFlow，那么这个过程甚至更简单。

这样的case如果再加上虚拟化会变得更加完美。让我们以安全为例。比如说利用像Check Point的软件刀片，我就可以创建虚拟防火墙实例来支持数据中心的多租户。用这种方式，我可以把多个应用放置在同一个物理防火墙上，利用虚拟化来分段保护网络安全，强制执行基于规则的访问控制策略，以便适应法规遵从需要。其次，如果再次结合OpenFlow，你还可以获得云计算所需的多层、多租户。

最后一种可能性是避开硬件设备，简单地将4-7层服务作为虚拟设备来实施即可。这样做会给我们带来创建标准镜像、快速配置和虚拟机迁移的好处。ESG研究公司指出，虽然大多数企业尚未搭乘数据中心虚拟设备的潮流，但是都对未来这么做非常感兴趣。一旦英特尔推出高密度多核服务时，大企业就将会在每台物理服务器上运行更多的虚拟机。而当这一情形发生时，虚拟设备肯定会更具吸引力。

这里最终的好处就是灵活性——数据中心经理们可以快速地用多种形式把网络带给4-7层服务。如此一来，数据中心网络就将能够实际支持虚拟数据中心、多租户和云计算。

那么，哪些厂商可以利用这一趋势而获得收益呢?这里列出的只是我首先想到的一些公司：

1. 思科。虽然该公司目前有些麻烦，但是它比其他任何一家公司都更为清晰地看到了数据中心网络的这种演进趋势。事实上，它的统一网络服务(UNS)就有点儿像“任意服务，任意位置，任意外观”的宣传口号。思科最近已两次将其关注点收缩在了安全领域上。它需要对WAAS和ACE做同样的事。

2. Juniper。Juniper几乎有着和思科一样丰富的产品线，而且在强力推广其SRX安全和QFabric。但是Juniper还是失去了一些ADC产品。尽管会有些重叠，但Juniper还是会与其友商Citrix或F5共同提供很好的产品与服务。

3. 惠普。惠普已经有了数据中心网络架构，但仅局限于4-7层的TippingPoint。虽然惠普与其合作伙伴一起创建了HP ProCurve ONE计划，但是还没看到有什么回报。业界还有谣传说惠普可能会购买一家防火墙公司(被提到的收购对象有Palo Alto、Fortinet和SonicWall)，也有可能会购买F5或者Riverbed。

4. 博科。博科已经拥有了非常好的数据中心网络架构故事，并且由于潜在强大的存储人群而占据了比较有利的市场地位。博科还因为其与McAfee的战略合作而获得了网络安全方面的优势，此外还有它自己的ADC技术，虽然这种技术很少为人所知，但的确很酷。还有一些合作伙伴将会帮助博科进入更广的市场。

其他厂商像Arista、Avaya、凯创、Extreme和Force 10等，虽然规模较小，但都是需要与之合作的4-7层服务提供商。Check Point也正在与很多主流厂商合作(思科与Juniper除外)。Crossbeam Systems和Sourcefire也应该算是这一领域中的佼佼者。

最后一点需要指出：我上面所描述的愿景虽然肯定是引人注目的，但很多企业的IT和网络专家们对于4-7层服务将在他们各自的环境中发挥怎样的作用没有清晰的概念。网络厂商应当以正确的信息、培训服务、现场工程设计以及系统集成等工作帮助这些专家认清这一愿景，只有这样，网络厂商才能拥有一个有利的市场地位。

我对SDN和OpenFlow的理解：
09年接触到OpenFlow，当时在梳理netfpga的开源工程，想在写的netfpga书里面选择几个典型的projects，感觉OpenFlow这个项目很有意思，把所有的网络处理抽象成了对flow的处理，用多个标识域对flow进行定义，关键是针对flow标识的查找过程，根据查找结果对flow进行操作。因为研究生期间的课题主要是网络算法硬件化，这里面的关键是协议header的mux、路由查找和NIDS的包内容扫描（字符串匹配算法的硬件化），所以感觉OpenFlow这个思路很有点将网络算法抽象化的意思。
但是当时一直没明白为什么要这么做？因为一直做网络算法硬件化，所以持续跟踪Nick课题组的动向，后来10年底接触到SDN，才明白是怎么回事。
这么说吧，SDN是一个新的网络生态系统，OpenFlow是众多实现SDN的一种开放协议标准，可以说OpenFlow的杀手锏就是开源，开放的态度，理解这一点非常重要，后续围绕SDN/OpenFlow做产品化思路的startup，一定要深度认识这一点。

那么为什么Nick想到了SDN，想到了OpenFlow呢？
先说SDN，Nick一再地把SDN与PC生态系统做比较，我们知道PC系统的每一次革新都会给硬件创造新的抽象层，比如最初的OS到如今的虚拟化，而支撑整个PC生态系统快速革新的三个因素是：
 Hardware Substrate，PC工业已经找到了一个简单、通用的硬件底层，x86指令集；
 Software-definition，在软件定义方面，上层应用程序和下层基础软件（OS，虚拟化）都得到了极大的创新；
 Open-source，Linux的蓬勃发展已经验证了开源文化和市集模式的发展思路，成千上万的开发者可以快速制定标准，加速创新；
再来看看网络系统，一方面路由器设计我们已经迷失方向了，太多复杂功能加入进来，比如OSPF，BGP，组播，NAT，防火墙，MPLS等，早期定义的“最精简”的数据通路已经臃肿不堪。另一方面从早期的动态网络到现在的NP，我们从来没有弄清楚一个Hardware Substrate和一个开放编程环境的清晰边界在哪里。
Nick认为如果网络生态也能效仿PC生态，遵循三要素，就可以迎来网络生态的大发展，而支撑SDN的关键是找到一个合适的Hardware Substrate，于是有了OpenFlow，描述了对网络设备的一种抽象，其基本编程载体是flow，定义flow，操作flow，缓存flow等，这个协议就是网络世界的flow指令集，它可以作为硬件架构和软件定义的一个桥梁，这个协议本身可以不断演进，下层的硬件架构可以跟着持续演进，上层的网络软件可以保持兼容，这样整个SDN生态圈就可以很好的持续发展。
另外，数据中心网络的出现，好像给OpenFlow带来了天然的用武之地，实际上查阅Nick早期的论文就明白：OpenFlow的来源是为了解决企业网管理问题的Ethane（paper，Ethane：Taking Control of the Enterprise）。从Nick以往的paper可以看出，他主要的强项是使得路由器设计可以量化分析（计算机体系架构-量化分析方法），随着他对企业网和数据中心网络的设备的研究，慢慢的有了OpenFlow的思想，然后有了对SDN的思考和布局。

SDN是一个用于数据中心网络的新的网络生态圈，OpenFlow是其中的一个关键环节，要实现SDN完全可以不采用OpenFlow（思科和Juniper不就是这么干嘛），除此之外，还包括运行在OpenFlow硬件底层上的网络OS-nox（http://www.noxrepo.org/），SDN仿真测试平台mininet（http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet），当然还有大量的网络上层应用。

SDN/OpenFlow中的产品化机会：
如果从早期持续跟进SDN/OpenFlow的话，你就会发现这个新东西的出现直至今天的火爆完全遵循Gartner的技术成熟度曲线，每年Gartner会发布一个Hype Cycles系列报告，用来描述每一项创新技术所经历的5个阶段：技术萌芽期，过热期，幻觉破灭期，复苏期，生产力成熟期，如下所示。

记得09年OpenFlow的概念刚出来时，很多人不以为然，认为不过是研究机构自己玩的新概念，等到了11年底，SDN和OpenFlow火起来时，很多人又蜂拥而上，觉得好像人人都有机会从中获取些什么。我的理解是，在技术浪潮风起云涌之际，总有人默默地分析，学习，充分理解，慢慢行动，不断修正，最终能做出一些东西的。甭管炒得有多火，要想很好的解答上面的问题，最重要的是如何在数据中心中快速地部署SDN，让用户用的很舒服（百度，腾讯等），作为一个平台支撑大量的应用。
先想一个问题：假如现在有一个做过很多年网络系统/网络设备设计的团队，在SDN/Openflow这么火爆的情况下，怎样才能抓住机会准确把握未来方向，做出占据一定市场份额的产品呢？
前面Google已经宣布自己利用OpenFlow部署/管理数据中心网络，硅谷截至目前已经涌现几个代表性的公司：Big Switch Networks，Nicira Networks等，而且众多巨头也已经拥了进来。对于小团队，小公司怎么办？实际上目前所有的公司都遵循两种思路：一是在现有网络/网络设备基础上尽快部署的问题，Nicira Networks的OpenvSwitch；二是全新的硬件架构，支持OpenFlow协议和SDN生态圈。
从我个人的理解，感觉这个产品化的思路要遵循“逐步打入SDN生态圈，产品化先部署后演进，同时要非常open”，具体的就是：
第一点先吃透SDN生态圈的方方面面（好比是一帮对SDN狂热，深度研究的技术文人），需要一个短小精悍的团队，一方面写写paper，编写SDN/OpenFlow技术书籍，跟进甚至加入OpenFlow协议起草，就跟无线通信协议的标准制定一样，只有充分融入SDN生态圈，慢慢在圈内打出口碑，才有机会切入进去；
第二点产品化先部署后演进（好比是一帮经验丰富能系统思考，且实干的工程师），根据自己前期技术积累逐步制定从SDN生态圈的那个方向去做产品化，同时要特别注意差异化。比如盛科，积累在网络处理芯片上，最终的介入点肯定也是IC，但是这里要理解几点：是在已有产品的基础上加支持OpenFlow的模块？还是针对OpenFlow协议演进方向做专门的系统芯片？我赞成同步进行，“先部署后演进”。关于差异性，不知是否接触过《破坏性创新》系列书籍，硅谷有个很有意思的新创公司vArmour Networks，这是当年netscreen几个大佬针对OpenFlow的startup，因为netscreen的安全背景，这个公司的目标就是将网络安全的方方面面跟SDN/OpenFlow结合起来做事情。说实话，我没有知道这个公司之前，还真没有把安全和OpenFlow放在一起系统的思考。
这里实际上需要考虑的事情非常之多，比如开发针对OpenFlow协议的系统芯片，pipeline查找表的设计，端口和流量的权衡，将nox移植到这个硬件架构上，将mininet仿真测试平台无缝结合。自己做出来的芯片跟市场上的相比是否有性价比。总之，肯定有很多不清楚的困难再等着。
但是我相信，只要充分理解SDN/Openflow，也就是方向明确，逐步介入ONF，结合盛科前面的技术积累，一定是可以做出一些成绩的。目前IDC预测到2016年SDN的商业价值是20亿刀，任何一个小团队只要能顺利进入这个市场，前景都是客观的。
第三点就是非常open（好比是一帮理解网络产品和应用的产品经理），从Nick把SDN/OpenFlow的推广来看，这一点非常之重要，任何时候都不能忘记，有这么几点：
 如果说只做针对OpenFlow的系统芯片，那就需要一个强有力的系统设备合作商，或者至少有一家愿意同舟共济的小系统厂商；
 必须有一个可以部署数据中心的合作伙伴，因为这个产品最终是否有竞争力，不光是自己关起门来搞搞，关键是需要与数据中心用户充分合作，比如百度，腾讯等，然后他们的大量的数据中心管理，安全应用都可以作为这个产品的测试床，看看google就知道了，他宣称自己成功部署OpenFlow在数据中心比什么都有号召力；
 在SDN/OpenFlow界充分交流，分享。通过不断的吸收和分析确定自己的产品化方向，也同时引导用户和业界的风向，Nick就是这么干的；
 开放是为了一起抱团，壮大，我感觉在SDN/OpenFlow生态圈，谁更艺术性，技巧性的open，谁最终就能走的更远，所以不看好思科等关起门来搞自己的SDN。

推荐一本书《Network Algorithmics: An Interdisciplinary Approach to Designing Fast Networked Devices》，非常不错。

OpenFlow并非实现网络变革的唯一途径

API和各种消息协议，包括一些标准在内，都可以让用户构建今天的软件定义网络(SDN)。不过，关键的问题是，并非所有人都能实现同样的网络，或者说都能用同样的方法去实现。那么，OpenFlow真能带领我们大家走同一条路去往SDN乐园吗?

OpenFlow是一套开源的API，可借助在某个集中控制单元上运行的软件，对来自多厂商的交换机和路由器实现网络编程，从而实现“软件定义的网络。OpenFlow是把对路由器和交换机的编程与底层硬件相分离，用软件对多厂商路由器和交换机的流量进行定义，从而实现流量管理和网络设计的一致性。

OpenFlow的支持者称，这套API及相关协议，还有SDN，会提供一个抽象层，或者说在网络控制与物理基础设施之间设置一个虚拟化层，将会让网络变得更加开放，可以实现更多的创新。

伦敦Info-Tech研究集团的分析师Derek Silva说，“我们都已认识到，要想管理跨多个数据中心的网络，且该网络还不归企业自己管辖，这种管理难度是非常复杂的，尽管我们在其他所有方面都在取得进展也是如此。“网络管理要求越简单越好，而我觉得由SDN运动和OpenFlow的推动者开放网络基金会所提出的未来愿景，有可能是实现这一目标的最佳途径。

但是其他一些因素也在发挥作用，比如流量控制器应摆放在什么物理位置上，这些因素正在让我们超出OpenFlow去看待某些问题。

咨询公司Internet研究集团的联合创始人Peter Christy说，“有关OpenFlow的讨论都假定控制器是放在某个分离的设备上的。一个合理的SDN配置是把控制器软件分发给每台交换机。在这种情况下，交换机内部实现正常的通信协议就没有意义了。

Christy认为，把控制器软件分发给每台交换机这样的SDN会改善交换机和控制器间的通信性能，改善SDN的运营。在他看来，Juniper的QFabric架构就是分发控制器的SDN的一个例子。

Arista网络则认为，它的交换机客户可以或者利用控制器，或者利用分布式网络控制来实现SDN。Arista称，这两种方法各有利弊，但是要实现一个综合性的SDN，两种方法都需要。

Arista定义了软件定义云网络的四大“支柱：云拓扑、分布式控制、网络虚拟化和管理/自动化。OpenFlow只是实现基于控制器的SDN管理/自动化支柱中的多种方法中的一种而已。其他的实现方法还有CLI、SNMP、XMPP、Netconf、OpenStack、VMware vSphere虚拟化软件等等。

Arista的CEO Jayshree Ullal认为，每一种方法都有实施案例。在她看来，OpenFlow的实施案例就是动态分组重定向，可用于网络分路汇聚、合法监听/电子监控(lawful intercept/CALEA)和拓扑不可知网络的分段部署等。

究竟哪种实施案例会获得广泛采纳还有待观察。

她对软件定义网络有全面普及的机会深表赞同。但是OpenFlow究竟会成为API、OpenStack、Netconf、XMPP、VMware，或者另一个hypervisor，则很难预测。Ullal称，所有这些方法都承诺可实现拓扑不可知网络虚拟化，可以为应用和工作负载的移动性进行优化。

在今年的VMworld大会上，Arista演示了如何用虚拟机的简单预配置来构建云，利用其EOS操作系统软件和CloudVision接口最多可实现5万个网络节点。XMPP是其CloudVision中的API。

“没有任何理由认为，明天不会出现一个OpenFlow或者OpenStack API，Ullal说。“但是现在就有一个完善定义的接口。我们今天用Netconf和XMPP，就是因为它很容易实现，各种规范定义完善，而且我们的一些客户对此很感兴趣。

Ullal说，Arista的EOS将支持一套API，可根据用户需求用于不同的“实施案例。目前，Arista正在调研OpenFlow的初期市场需求，并在数据中心内试验将流量重定向给分路器和分路汇聚器。

“一项新的技术当然不会排除其他也能改进现有技术的务实方法，她对SDN如是评论说。“在普遍使用的遗留运营环境中，改进现有技术甚至比创新更重要。

在Ullal看来，并非OpenFlow在推动SDN，而是SDN在推动OpenFlow。

“OpenFlow与更广泛的SDN API的结合，对于OpenFlow能否获得更广泛的部署来说是至关重要的，她说。

OpenFlow控制器厂商Big Switch网络的联合创始人Kyle Forster认为，在今天的市场中，SDN还没有热到能给OpenFlow以市场动力的地步。很多API都必须加以剪裁才能适应某个特殊的“实施案例，这也说明市场对于网络编程的需求很少。

“在众多的编程方法中，厂商们都在试图让API变得非常具体，这样一来，第三方厂商要想靠在这些非常具体的API上写程序来赢利就很不容易了，他说。“已经有很多人认识到，除非有某种标准底线存在，否则要想创建OpenFlow的第三方应用生态系统几乎是不可能的。

“OpenFlow非常重要，但它不能因此而成为唯一选择，Forrester分析师Andre Kindness说。“它只是众多选择之一。它之所以能吸引众多厂商，是因为有大量的社区在为其开发，有很多人才在为其工作。它正在引发众多的讨论，和新的思维方式。

OpenFlow能解决私有云网络VLAN问题么

在关于私有云网络的文章中，我们首先探讨了物理网络是否影响私有云。本文我们将讨论如何通过软件定义网络控制面板整合虚拟和物理交换层。

　　私有云网络网络必须在灵活性和动态性上优于传统网络。实际上，私有云必须使用软件定义网络，建立一种服务与底层虚拟和物理基础架构相分离的网络，最终实现网络即服务(NaaS)。

　　然而，除了专有的实现技术，想要在使用多个供应商和多种虚拟机管理程序的私有云中实现NaaS/SDN，我们还需要解决很多问题。

　　私有云网络：管理覆盖虚拟和物理设备的VLAN

　　首先，私有云网络具有两个交换层：虚拟交换层和物理交换层。物理交换机是我们20多年来一直使用的以太网交换机。虚拟交换层是各种虚拟机管理程序的组件。大多数虚拟机管理程序架构都通过一个通用控制面板连接虚拟交换机，构成一个大型的分布式虚拟交换机。市面上现有的一些改进的虚拟交换机，以及仍在不断发展的开放系统虚拟交换机都是：Open vSwitch。

　　虚拟和物理交换机仍然是两个不同的网络实体，它们必须一同实现私有云。大多数网络架构师使用VLAN连接这两种设备，但是这要求物理和虚拟交换机处于锁步状态。

　　一种可行的方法是，在配置数据中心的所有线路和端口上配置所有可能的VLAN。然而，这种万能方法可扩展性很差，而且具有非常大的配置错误风险，以及可能存在安全性和合规性问题。另一个方法是实现一种VLAN学习解决方案，动态管理虚拟和物理网络的VLAN，特别是在VM发生迁移的时候。有一些解决方案很好用，但是它们是私有的。边缘虚拟桥接(EVB) IEEE 802.1qbg是一个正在开发的VLAN学习和映射标准。

　　NVGRE和VXLAN：支持3层协议VLAN

　　私有云网络VLAN必须使用大规模桥接技术，才能支持VM迁移和通信。这种方法可扩展性差，也不支持3层协议负载分发。为了解决这些VLAN问题，目前有两个得到多个供应商支持的协议可以使用：VXLAN (Virtual Extensible LAN)和NVGRE (Network Virtualization using Generic Routing Encapsulation)。VXLAN和NVGRE是IFTF草案协议，支持在IP层中封装MAC层流量。通过利用更高层协议，我们就能够在3层协议上分发负载，而VM仍然保留在2层网络上。这种技术非常不错，因为它打破了位置与身份之间的固有联系。这意味着，即使VM移动了另一个子网，它仍然能够保留原来的IP地址。这种方法可行，但是性能可能会受到一些影响。

　　VXLAN和NVGRE在私有云网络中应用的缺点

　　对于实现更为动态和更具可扩展性的私有云网络而言，VXLAN和NVGRE的出现是一个很大的进步，但是它们也不是完整的解决方案。它们是封装的协议，还不具备控制面板。相反，它们还依赖于其他的网络功能。例如，VXLAN依赖于与协议无关的多路广播(UDP PIM)，而且建立VM之间的通信必须通过2层淹没和动态MAC地址学习实现。

　　而且，VXLAN和NVGRE还无法解决在核心网络扩展2层域所面对的基础问题：“网络长号”。即使两个VM位于同一个交换机上，流量仍然需要先转发到核心网络，然后到达目的地，感觉就像是乐器长号的管子一样。这就像是在使用学生火车优惠票一样，原先住在城市A，后来搬家到城市B，但是如果一定要享受优惠，您也只能先买到城市A的票，然后再去新家所在的城市B。这样的架构效率很低，而且无法扩展。最后，VXLAN是一个虚拟结构，无法连接到一些物理设备，如防火墙、负载均衡器等。

　　SDN能否解决私有云网络的VLAN问题?

　　除了VXLAN和NVGRE，我们还需要一个强大的控制面板，用于整合虚拟和物理交换机。在开放标准方面，最令人兴奋的是开放网络基金会(ONF)的OpenFlow项目。OpenFlow将控制应用程序(控制器)从底层数据程序(交换机)剥离。

　　OpenFlow将会采用一种全新方法，实现虚拟和物理交换机之间的数据包转发，从而不需要封装、标记和VLAN，但是仍然支持多租赁、VM移动和可扩展性。这将真正成为交付NaaS作为私有云一部分的SDN。

　　但是，关键词是“将来”，因为OpenFlow实现仍在变化中，而且进展不快。重点在于交换机供应商对SDN/NaaS和OpenFlow的支持。我们需要在私有云网络中抛弃VLAN。VXLAN和NVGRE是其中关键的部分，但是它们不是最终的解决方案。

OpenFlow技术及应用模式发展分析

近来OpenFlow的话题比较多，INFOCOM上清华土著又给上了一课，就找了些资料学习了一下，顺带编写了这篇科普文章。感谢许多朋友在撰写过程中的帮助和启发，另外yeasy兄发在弯曲的系列文章也非常有价值。很喜欢LiveSec团队的开放心态，希望能帮他们的产品和理念做尽量广泛的传播。

原文发于《计算机世界》。顺带说下，最近要做NFGW的选题了，感兴趣的朋友来找我吧，Email和GTalk是hanxu0514 aT gmail dOt com。

4月10日至15日，第30届IEEE计算机通信国际大会 (INFOCOM 2011)在上海国际会议中心隆重举行。本次会议吸引了国内外1000多名计算机和通信领域的专家、学者和企业的科研人员到场，重点围绕云计算、网络安全、数据中心网络、移动互联网、物联网等一系列研究领域的前沿问题进行了深入的探讨。在倍受关注的现场展示环节中（Live Demo），来自清华大学信息技术研究院网络安全实验室的师生们展示了基于OpenFlow的网络安全管理系统LiveSec，引起了与会者的普遍关注。该系统的成功运行，是国内通信领域的研发团队对前沿技术跟踪、创新工作的完美诠释，在科研成果转化为可用产品的道路上占据了先机。

OpenFlow扬帆起航

OpenFlow技术最早由斯坦福大学提出，旨在基于现有TCP/IP技术条件，以创新的网络互联理念解决当前网络面对新业务产生的种种瓶颈，已被享有声望的《麻省理工科技评论》杂志评为十大未来技术。它的核心思想很简单，就是将原本完全由交换机/路由器控制的数据包转发过程，转化为由OpenFlow交换机（OpenFlow Switch）和控制服务器（Controller）分别完成的独立过程。转变背后进行的实际上是控制权的更迭：传统网络中数据包的流向是人为指定的，虽然交换机、路由器拥有控制权，却没有数据流的概念，只进行数据包级别的交换；而在OpenFlow网络中，统一的控制服务器取代路由，决定了所有数据包在网络中传输路径。OpenFlow交换机会在本地维护一个与转发表不同的流表（Flow Table），如果要转发的数据包在流表中有对应项，则直接进行快速转发；若流表中没有此项，数据包就会被发送到控制服务器进行传输路径的确认，再根据下发结果进行转发。

OpenFlow网络的这个处理流程，有点类似于状态检测防火墙中的快速路径与慢速路径的处理，只不过转发与控制层面在物理上完全分离。这也意味着，OpenFlow网络中的设备能够分布部署、集中管控，使网络变为软件可定义的形态。在OpenFlow网络中部署一种新的路由协议或安全算法，往往仅需要在控制服务器上撰写数百行代码。加州大学伯克利分校的Scott Shenker教授对此有着很到位的评价：“OpenFlow并不能让你做你以前在网络上不能做的一切事情，但它提供了一个可编程的接口，让你决定如何路由数据包、如何实现负载均衡或是如何进行访问控制。因此，它的这种通用性确实会促进发展。”

在得到学术界的普遍认可后，工业界也开始对这项新技术表达出浓厚的兴趣。OpenFlow已经在美国斯坦福大学、Internet2、日本的JGN2plus等多个科研机构中得到部署，网络设备生产商思科、惠普、Juniper、NEC等巨头也纷纷推出了支持OpenFlow的有线和无线交换设备，而谷歌、思杰等网络应用和业务厂商则已将OpenFlow技术用于其不同的产品中。就在半个月前，以OpenFlow为产品核心设计理念的初创企业Big Switch Networks成功完成了总额1375万美元的第一轮融资，标志着资本市场对这项新技术及其发展前景的充分认可。目前，OpenFlow的推广组织开放网络基金会（Open Networking Foundation）的成员基本涵盖了所有网络及互联网领域的巨头。

好用才是硬道理

使用新技术的代价往往十分高昂，好在OpenFlow具有足够的开放性，给在传统网络中的融合实现带来可能。清华大学信息技术研究院网络安全实验室在本届INFOCOM大会上现场展示的部署在清华大学信息楼内的LiveSec网络安全系统，就是一个非常好的范本。该系统在传统的以太网之上，通过无线接入技术和虚拟化技术引入了基于OpenFlow协议的控制层，显著降低了构建成本。

LiveSec网络安全系统包含三层架构：

以太网交换层: LiveSec基于传统的以太网络进行物理交换，所有的执行OpenFlow协议的接入设备通过传统以太网互联。
OpenFlow控制层: LiveSec使用支持OpenFlow协议的虚拟交换机（Open vSwitch）和无线路由器构成接入网络层。OpenFlow控制层构成LiveSec的逻辑拓扑，并由LiveSec控制器进行集中控制。
网络用户和服务节点: 网络用户通过无线路由器接入，服务节点通过虚拟交换机接入。所有接入流量在接入层受到LiveSec控制器的全局策略控制。

基于上述架构，LiveSec相对传统的安全部署模型具有多重优势。首先，该系统解决了安全设备的可扩展问题。通过全局细粒度的负载均衡，LiveSec支持安全设备在网络的任意位置进行增量式部署。新部署的节点会按照OpenFlow协议自行入网，并自动将控制权交由LiveSec控制器。所有的用户和服务节点均可在LiveSec网络内动态迁移，包括无线接入和虚拟机的无缝迁移。记者在展示现场尝试进行了基于虚拟机的服务节点动态加入网络的实验，当具有安全检测能力的虚拟机加入网络中时，LiveSec的可视化界面会显示出该虚拟机在网络中的拓扑及其具备的业务能力（如杀毒功能，协议识别功能等）。LiveSec控制器会依据新增节点的处理能力将需要安全处理的网络流量均衡到新的节点上，从可视化界面中也可以看到新增节点引起的链路流量变化。

传统网络中，安全设备一般被部署在边缘，对进出流量进行访问控制。这种方式虽然成熟有效，对内网中的安全问题却无能为力。LiveSec创新的交互式访问控制特性则能很好地解决这一难题，由于系统提供了安全节点到控制器的信息交换通路，并针对安全事件设计了一套信息交换协议，LiveSec可以根据安全节点传来的安全事件，在用户接入层实施访问控制。这意味着，该系统做到了全网的点到点安全控制，任何攻击流量在不离开接入交换机的情况下就被扼杀在萌芽状态，内网安全的顽疾可以从根本上得到解决。

在OpenFlow网络中，控制服务器管控着所有的数据流，又能实时感知其他节点的状态，为可视化提供了足够的基础。记者在展示中看到，LiveSec结合OpenFlow协议以及应用层业务识别服务节点，将网络中所有的拓扑、流量、应用、安全变化都按照统一格式写入中央数据库，并在动态界面中实现了包括当前状态及历史事件回放在内的全网业务可视化。当使用无线设备的用户通过OpenFlow无线路由器接入后，立即会显示在系统的可视化界面中。该用户上网所涉及的应用层协议，也会实时显示在用户图标一侧。当用户访问不良网站或者进行攻击时，图标上会出现红色警示，LiveSec也会依据安全策略在用户接入端实时阻止用户的部分或所有流量。历史回放功能也相当实用，可以回放特定时间段内LiveSec的所有事件，攻击发起者包括地理位置在内的所有信息均可以通过数据库查找获取。

图4. 在清华大学信息楼部署的LiveSec系统

商业模式定成败

虽然OpenFlow网络从根本上解决了传统网络存在的很多问题，却也因标准化过程刚刚起步，缺乏大众化的、实用的落地方案，至今仍然多被用于各类实验性质的网络。在其发展的道路上，势必还要经历扩大用户规模和商业模式创新两大阶段。而纵观近年来IT行业巨头们的发展情况，缔造一个成功的商业模式，其重要性显然远远超过了技术创新。

在记者看来，LiveSec在某些技术以外环节上的创新，对OpenFlow的推广有着十分积极的意义。该系统将传统安全网关的数据平面拓展到整个网络之中，以全网内的OpenFlow交换设备作为数据转发平面。并且为了保证可扩展性并降低成本，保留了传统的以太网交换设备，仅通过引入支持OpenFlow协议的接入层网络来实现逻辑拓扑的全网可控。这意味着，有着一定研发能力的用户可以利用廉价的硬件平台和开源软件，自行搭建低成本的OpenFlow网络。据LiveSec团队负责人亓亚烜博士介绍，该校信息楼内实验网络的建设大量采用了传统的以太网交换机和无线接入点，OpenFlow控制层则由运行着开源的Open vSwitch模块的电脑和支持OpenFlow协议的第三方无线接入点固件DD-WRT实现，从而建立了一个低成本、高性能的OpenFlow网络。

未来的数据中心网络越来越趋向于由虚拟机和服务器群所组成，数据中心的交换架构则趋向扁平，使用高性能交换机群组或clos 网络甚至可以支持百万个节点的无阻塞互联。在这种情况下，网络服务质量及高可用性成为用户最为关心的问题。以LiveSec为代表的基于OpenFlow的网络操作系统支持网络设备的分布式部署，有效避免了单点失效问题。控制服务器的分布式部署，则可以利用分布式哈希技术同步全网拓扑和策略。当网络出现局部故障时，系统可以利用OpenFlow协议迅速构建全新的互联拓扑，甚至可以为不同的业务和应用分别构建不同的拓扑，以满足安全和服务质量的需求。这又是新的商业机会，试想一下，在OpenFlow网络的支持下，IaaS提供商可以为用户交付一个独一无二的网络，用户甚至可以自行设定数据流在本网内的路径和安全策略，而不仅仅是几个虚拟设备的控制权。

从系统实现模式的角度看，LiveSec的模式是构建网络操作系统（基于开源项目Nox），这个发展方向已经被许多业内人士所认同。不管对象是桌面还是网络，操作系统存在的根本意义都是管理设备和提供编程接口。众所周知，想发挥一块高性能显卡的处理能力，必须先安装该硬件的驱动。基于OpenFlow的网络操作系统也是如此，仍以LiveSec为例，所有OpenFlow交换设备和安全服务节点都可看作网络系统中的硬件设备，安全业务的实现则通过服务节点上的软件完成。当新的服务节点加入网络时，LiveSec控制器首先要知道这个节点能处理什么业务，以及如何与设备建立通信机制，才能让安全处理的执行者和决策者有效地互动起来。出于商业层面的考虑，这种机制的建立往往由服务提供者主动告知控制器，需要一个与电脑安装硬件驱动十分相似的过程。对网络管理者来说，这个步骤简化了部署及使用难度；而对设备制造商而言，这种方式也有利于将现有针对传统网络的产品快速移植到OpenFlow网络中。

受当前流行的运营模式影响，基于OpenFlow的网络操作系统也在加入更多的应用发行元素。当用户在控制台中添加服务如同在App Store获取应用般便捷时，OpenFlow网络的建设必然会步入高速发展阶段。实际上，这种发行模式与当前许多云安全服务的商务模式是可以无缝对接的，为云安全的落地提供了绝佳的渠道。以抗DDoS需求为例，在用户购买对象大量地由专用设备转向清洗服务的今天，供应商可以通过系统内置的发行体系为用户提供自助服务，然后按次数或处理能力收取费用；用户完全不必考虑现实中令人头疼的部署问题，只需通过“软件商店”下载安装相应服务，就能为OpenFlow网络添加抗DDoS的能力。

附：

世界首个大型100G OpenFlow SDN网络接近完成

ugmbbc发布于 2012-07-10 12:30:05

Internet2正接近完成其OpenFlow 100G以太网SDN项目，该项目是为了测试大数据的汇编与研究应用的交付而发起的。在本周于斯坦福大学召开的夏季2012 ESCC/Internet2联席技术会议上，300名从事Internet2项目的网络工程师们将合作决定哪些技术和功能可以搬到创新平台 (Innovation Platform)上来，而该平台被Internet2宣称为美国首个开放SDN网络。

迄今为止，已有超过20家Internet2成员大学和区域网络受邀成为首批试用该平台的合作者。该平台的接入链路为10G和100G以太网。Internet2已经为2层VLAN的预配置编写了一个基于OpenFlow的SDN应用。

新近添加到这一基础设施架构的是来自博科和瞻博的100G以太网OpenFlow路由器，大约在35到45个站点上部署。博科的MLX和 NetIron系列，以及瞻博的MX系列路由器能够从一台开源的NOX SDN控制器上对创新平台进行编程控制，以便加快规模服务和智能服务的交付进度。

作为一个SDN网络，该创新平台旨在推进教育、校办企业以及全球的大数据协作研究成果，以便从事新的研究计划，研究新的全球经济发展周期。 Internet2组织称，借助网络的“切片化”，或者为应用开发隔离不同网络子集的能力，该平台的可编程性将会进一步促进跨不同开发社区的应用开发创新。

该平台还允许Internet2构建一个SDN“应用商店”，开发人员可在此为研究和教育社区提供新的应用以供试用。

Internet2负责网络服务的副总裁Rob Vietzke说，“Internet2社区将SDN看成是和初期的互联网相同的一次变革机遇。在构建这一全新的全国范围的SDN环境方面，我们的投资力度相当大，我们想用它来做一个软件开发平台。”

对于大数据而言，美国各大实验室和大学的协作研究人员所产生的海量数据集正呈现出指数增长趋势，而该创新平台就可以让成员机构与如此规模的数据增长保持一致的步调。不过Vietzke还预计道，谷歌和Facebook等公司所产生的数据量和大学机构相似，因此也有可能会使用创新平台。

创新平台是今年初由Internet2所发起的一个项目，作为其NDDI项目以及NSF(美国国家科学基金会)的GENI计划的一个补充。当时的宣传口号是，投资9650万美元兴建一个由研究和教育社区所拥有的全国规模的SDN网络。

Vietzke认为，“SDN所能做的多域名、广域视角是独一无二的。如果我们回到网络的早期，当时的网络堆栈都是开放的，校园里的人们开始时叫这个东西为TCP/IP，后来又觉得有必要把它叫做SDN，再后来又叫邮件传输——所有这些东西都是在那个网络和协议堆栈开放的时期出现的，人们可以在上面进行各种创新。我们希望现在的这个带30多个节点、全国范围的100G骨干网SDN可以提供相同的创新温床。”

美国国家电信与信息管理局(NTIA)的宽带技术机会计划(BTOP)为了支持美国统一社区锚点网络(UCAN)项目，资助了Internet2的网络升级。UCAN让美国的各类“锚点”机构，包括图书馆、大学、医院、K-12学校、社区大学以及公共安全组织在内的20多万家机构都能享受到各种高级的网络功能。

这些功能包括高清和视频组播的远程学习和远程医疗应用，这些高级功能不可能使用消费者级别的互联网服务来实现。

Vietzke预计，在不久的将来，还会有其他多家“大厂商”为创新平台推出OpenFlow产品。

“互联网之父”文顿-瑟夫在创建了43亿个IP地址之后，不知是否预料到互联网发展如此之快，短短四十年，人们就要面对IPV4地址枯竭的现实。于此同时，随着互联网的进一步发展，用户对于网络性能的要求进一步提高，越来越多复杂的功能例如OSPF、BGP、组播、区分服务、流量工程、NAT、防火墙、MPLS等都被纷纷塞进了路由器等交换设备里面，从而使交换机不堪重负。这时，有人提出，如果能有一个开放接口、支持控制的交换标准该有多好？就像计算机领域有一个简单可用的硬件底层(X86指令集)，那么网络是不是也可以复制计算机领域的成功呢？于是，OpenFlow便应运而生。

OpenFlow由斯坦福大学和加州大学伯克利分校领导的大学联盟所发起，他们的初衷是让研究人员可将企业级以太网交换机作为定制构件用于大学的网络实验。他们希望服务器软件能够直接访问交换机的转发表，因此他们研发了OpenFlow协议。该协议用于修改、转发、排队和剥离匹配数据包的基元。OpenFlow与用于网络的x86指令集相似，可创建在软件层上，也就是说用户可以定义数据流并侦测这些数据流以何种途径通过网络，且上述过程完全无需涉及底层硬件。

在OpenFlow网络中，L2交换机的许多控制平面功能，如生成树协议、MAC地址学习等均由服务器软件而不是交换机固件决定。早期研发人员在定义协议时想的更远，他们允许OpenFlow控制器和交换机执行许多传统的控制功能(如路由、防火墙和负载平衡)。说得简单点儿，人们想要控制Internet，最直接的办法就是控制网络中最为关键的节点–交换设备，一旦可以实现这一目的，那么所有的流量便可以为我所用，这时便需要有一套开放接口、支持控制的交换标准，而这便是OpenFlow。目前，OpenFlow协议已经走出大学实验室。

OpenFlow是把网络流量的控制权从基础设施交换机和路由器等手中收了回来，交到了网络所有者、个人用户或个别应用的手中。用户有了这个控制全便可制定策略，为工作流寻找有可用带宽、低延迟或低阻塞，低跳数的路径。

业界对OpenFlow的前景看法不一。有人认为OpenFlow对于数据中心、私有云以及园区网的负载均衡、流量控制和虚拟网络特别有用，因为在这些场合中，网络设备和虚拟机会成倍增加，使网络拓扑不堪重负。有人认为，OpenFlow之于网络有点儿像VMware之于虚拟化，它可以对由相互不兼容的路由器和交换机构成的网络进行统一控制。不过Openflow可谓网络虚拟化领域中重要的探索。从目前的行业趋势来看，网络设备厂商思科对Openflow的态度仍然不明朗，业内分析思科可能是基于Openflow这样开源的SDN（软件定义网络）被广泛接受，思科很可能失败。与思科这种低调的态度表示，惠普把 OpenFlow作为了网络份额稳步攀升的发力点，HP更是16款以太网交换机产品中支持OpenFlow，以试图在OpenFlow市场分得一杯羹。此外，IBM和NEC在龙年伊始，宣布联合向用户提供OpenFlow交换设备，合作开发OpenFlow交换机和软件定义网络。

虽然IBM并不是主流网络供应商，但是它是世界上最大型IT供应商之一，也有很长的网络产品研发历史。IBM加入OpenFlow大潮引起了一定的关注，但是OpenFlow是否真的能够改变网络尚不明确。目前OpenFlow还并不完善，尚存在许多问题待解决，而且涉及的面非常广，其中牵涉到用户需要有足够的软件开发力量。要想实现软件定义的互联网，还需要得到业界全方位的支持和努力才能梦想成真。不过很多大公司共同组建了开放网络基金会，极力推进OpenFlow实现的软件定义网络，相信OpenFlow标准规范的制定已经不远了

切片

带宽：每个切片应该具有专门的总可用带宽百分比。

拓扑结构：每个切片对于网络节点（包括物理和虚拟交换机及路由器）应该有自己的“看法”.切片的组成部分应该是不知道切片的：对于控制器而言，FlowVisor看起来就是普通的交换机；从OpenFlow交换机的角度来看，FlowVisor就是一个控制器。

流量：根据上述规则设置，流量应该严密地始终如一地隔离到一个特定切片或者多个切片。

设备CPU:重载物理交换机可以丢掉缓慢路径的数据包。网络管理员会更新OpenFlow统计计数器和规则，所以在评定限速密集命令时，FlowVisor应该考虑CPU资源。

转发表：由于转发表往往被限定在物理设备上，网络管理员应确保一个切片不会影响任何特定设备的转发表，迫使它放弃另一切片的规则。

FlowVisor准备好迎接广泛应用了吗？

与其构建块OpenFlow一样，FlowVisor能够帮助研究人员快速灵活地在大型生产环境对新的SDN理念和工具进行实验。目前FlowVisor被部署在美国各地的生产环境中，特别是在大型校园（例如斯坦福）。此外，两个以研究为重点的大型网络--全球网络创新环境（GENI）和Internet2也在使用FlowVisor.

FlowVisor网络虚拟化的风险和优势

“如果你将OpenFlow交给未受过相关教育的社区，这就类似于将上膛的枪交给小孩，并告诉他们瞄准自己和扣动扳机，”他警告说，“而对于运营商而言，OpenFlow有着巨大的优势。例如，我曾在MCI（运营商）工作多年，如果当时我们有OpenFlow,将能帮助我们解决很多问题。”

FlowVisor网络的光明前景

Sherwood表示，FlowVisor的影响力可能最终也与OpenFlow相同。“我们正试图将大家注意力聚焦在FlowVisor代码上，”他指出该项目还引入一名谷歌代码夏令营实习生来帮助改善和提高其知名度，“随着环境不断完善，人们将会看到网络切片的价值。

nox是一个开源的openflow控制器，经过测试，安装步骤如下：

1 操作系统的选择，经过测试，我只在ubuntu 10.04上安装成功，在centos fedora ubuntu 11上安装均因为依赖包的原因，安装失败

2 安装

cd /etc/apt/sources.list.d

sudo wget http://openflowswitch.org/downloads/debian/nox.list

sudo apt-get update

sudo apt-get install nox-dependencies

git clone git://noxrepo.org/nox

cd nox

如果需要启动gui 必须做branch这一步

git branch -a

git checkout -b destiny origin/destiny

./boot.sh

mkdir build/

cd build/

../configure

make -j 5

启动控制器

./nox_core -v -i ptcp:6633 monitoring

apt-get install python-qt4 python-simplejson

注意这里，我在这一步卡了好几天，就是因为没有安装下面的包，而且官方文档没有说明

apt-get install python-qt4-sql

让openvswitch连接到控制器

ovs-vsctl set-controller br0 tcp:172.16.1.230

NOX是加州大学伯克利分校和斯坦福共同开发的下一代网络控制平台，详细信息请参见noxrepo.org和openflowswitch.org。

这篇文档介绍对NOX的安装，使用和开发。

NOX是一个网络控制平台。它的目的是提供一个编程界面，基于它，可以建立网络管理和控制的应用。NOX被设计支持具有数百个交换机和数万到数十万用户的大型企业网络，和只有一个低性能的嵌入式交换机的家庭网络。

基于NOX的应用可以对网络进行流级别的控制。这意味着，它们可以决定哪些流允许访问网络，它们的路由路径是什么。而且，NOX为应用提供了网络的抽象视图，包括网络拓扑和所有检测到主机的位置。

NOX通过OpenFlow协议控制网络交换机。所以它需要网络上有至少一个支持OpenFlow的交换机。NOX支持由OpenFlow交换机和传统的L2交换/L3路由共同组成的混合网络，这保证了NOX对目前网络体系结构的向后兼容性。

什么是NOX和NOX怎样工作？

NOX是为企业网和家庭网开发管理功能的一个开放平台。NOX运行在通用硬件上，并提供了一个软件环境，基于该软件环境，各种程序可以实时控制大规模高速网络。NOX提供以下：

1。NOX基于非常廉价的交换机而提供复杂的网络管理（management），网络可视化(visibility)，网络监控(monitoring)，网络访问(access control)控制等功能。

2。开发者能够加入他们自己的控制软件，而且，不像标准基于*nix的路由器，NOX提供了以线速管理和控制硬件交换机的接口（OpenFlow）

3。NOX提供了面向网络整体的一次性编程模型，即：一个程序可以控制网络上所有交换机的转发决策机制。这使得程序开发比标准的分布式方式简单的多。

如下图所示，NOX的控制软件运行在单一的商用PC上，管理多个交换机的转发表。

NOX提供编程接口，基于该接口，很多不同的网络程序（应用）可以运行。这些应用可以“勾到”网络事件，访问流量，控制交换机转发决策，和生成流量。
NOX通过对网络流进行操作而不是对每个数据包操作来达到它的可扩展性。对于网络中的每个新到达流，它的第一个数据包被送给NOX，NOX通过事件机制再转发给感兴趣的应用。这些应用就可以：决定是不是或怎么样在网络上转发该流；收集统计信息；修改流中的数据包（如，增加VLAN标记，进行NAT转换等）；或者查看同一个流中更多的数据包以获得更多信息。
这种流级别的网络视图为应用提供了强有力的控制手段。重组网络拓扑，跟踪网络上的主机移动，提供适当粒度的网络访问控制，管理网络历史，重组网络历史状态等应用已经在NOX上建立起来了。

从操作系统到网络操作系统

早期的计算机程序开发者直接用机器语言编程。因为没有各种抽象的接口来管理底层的物理资源（内存、磁盘、通信），使得程序的开发、移植、调试等费时费力。而现代的操作系统提供更高的抽象层来管理底层的各种资源，极大的改善了软件程序开发的效率。

同样的情况出现在现代的网络管理中，管理者的各种操作需要跟底层的物理资源直接打交道。例如通过ACL规则来管理用户，需要获取用户的实际IP地址。更复杂的管理操作甚至需要管理者事先获取网络拓扑结构、用户实际位置等。随着网络规模的增加和需求的提高，管理任务实际上变成巨大的挑战。

而NOX则试图从建立网络操作系统的层面来改变这一困境。网络操作系统（Network Operating System）这个术语早已经被不少厂家提出，例如Cisco的IOS、Novell的NetWare等。这些操作系统实际上提供的是用户跟某些部件（例如交换机、路由器）的交互，因此称为交换机/路由器操作系统可能更贴切。而从整个网络的角度来看，网络操作系统应该是抽象网络中的各种资源，为网络管理提供易用的接口。

实现技术探讨

模型

NOX的模型主要包括两个部分。

一是集中的编程模型。开发者不需要关心网络的实际架构，在开发者看来整个网络就好像一台单独的机器一样，有统一的资源管理和接口。

二是抽象的开发模型。应用程序开发需要面向的是NOX提供的高层接口，而不是底层。例如，应用面向的是用户、机器名，但不面向IP地址、MAC地址等。

通用性标准

正如计算机操作系统本身并不实现复杂的各种软件功能，NOX本身并不完成对网络管理任务，而是通过在其上运行的各种“应用”（Application）来实现具体的管理任务。管理者和开发者可以专注到这些应用的开发上，而无需花费时间在对底层细节的分析上。为了实现这一目的，NOX需要提供尽可能通用（General）的接口，来满足各种不同的管理需求。

架构

组件

下图给出了使用NOX管理网络环境的主要组件。包括交换机和控制（服务）器（其上运行NOX和相应的多个管理应用，以及1个Network View），其中Network View提供了对网络物理资源的不同观测和抽象解析。注意到NOX通过对交换机操作来管理流量，因此，交换机需要支持相应的管理功能。此处采用支持OpenFlow的交换机。

操作

流量经过交换机时，如果发现没有对应的匹配表项，则转发到运行NOX的控制器，NOX上的应用通过流量信息来建立Network View和决策流量的行为。同样的，NOX也可以控制哪些流量需要转发给控制器。

多粒度处理

NOX对网络中不同粒度的事件提供不同的处理。包括网包、网流、Network View等。

应用实现

NOX上的开发支持Python、C++语言，NOX核心架构跟关键部分都是使用C++实现以保证性能。代码可以从http://www.noxrepo.org获取，遵循GPL许可。

系统库

提供基本的高效系统库，包括路由、包分类、标准的网络服务（DHCP、DNS）、协议过滤器等。

SDN和Openflow flowvisor NOX

简介