目录
1起源
2SDN简介
3OpenFlow网络简介
3.1OpenFlow架构
3.1.1 控制器（controller）
3.1.2 OpenFlow交换机（OFSwitch）
3.1.3数据包在交换机中的匹配处理
3.2Flowvisor
3.2.1Flowvisor综述
3.2.2融合FlowVisor的OpenFlow网络
3.3OpenFlow的应用
4OpenFlow版本之间的区别
4.1OpenFlowVersion 1.1
4.2OpenFlowVersion 1.2
4.3OpenFlow version 1.3
4.4区别综述
5SDN/OpenFlow发展
5.1学术研究组织
5.1.1ONF
5.1.2IETF
5.1.3ITU-T
5.1.4ETSI
5.1.5CCSA..
5.2技术实现方面
5.2.1Nicira公司
5.2.2Big Switch Networks.
5.2.3Insieme Networks
5.2.4IBM
5.2.5华为
5.3协议应用
6附录1开展SDN项目的机构及研究情况
6.1Sane项目
6.2Ethane项目
6.3CLEANSLATE项目
6.4HyperFlow
6.5ONIX.
6.6master-slave模式的分布式控制架构
6.7ASIC
6.8NOX
6.9defane
6.10FlowScale
6.11Aster*x
6.12ElasticTree.
6.13SODALES（无线方向）
6.14其他..
6.14.1智能宽带接入网
6.14.2华为PON网络SDN发展计划
1、起源
网络早已经成为支撑当代人们生活、娱乐、工作、学习等各个方面的基础性设施之一。然而，当今网络的架构越来越不可以满足运营商、企业和用户等的需求。传统互联网由极其复杂的交换机、路由器、终端以及其他设备组成，这些网络设备使用着封闭、专有的内部接口，并运行着大量的分布式协议。在这种网络环境中，对于网络管理人员、第三方开发人员(包括研究人员)，甚至设备商来说，网络创新都是十分困难的。近年来，SDN以软件进行定义网络，结合网络虚拟化的技术正在对网络的发展发挥越来越大的作用，并且越来越因此业界的重视。
SDN是软件定义网络的简称，其核心理念是使网络软件化并充分开放，从而使得网络能够像软件一样便捷、灵活，以此提高网络的创新能力。通常意义上来讲，SDN是指从OpenFlow发展而来的一种新型的网络架构，其前身是斯坦福的用于企业集中安全控制的Ethane项目”。2008年斯坦福大学的Nick Mckeown教授将其命名为0penFlow，后经由斯坦福Clean state项目推广，以及在大型网络一全球网络创新环境(GENI)项目中的应用，该概念被逐渐扩展并成为了SDN。
2、SDN简介
图 2‑1描述了SDN架构的逻辑视图。SDN的基本网络要素包括：逻辑上集中的SDN控制器，它是基于软件的控制器，负责维护全局网络视图，并且向上层应用提供用于实现网络服务的可编程接口(通常也称为“北向接口”)；控制应用程序，该程序运行在控制器之上，通过控制器提供的全局网络视图，控制应用程序可以把
整个网络定义成为一个逻辑的交换机，同时，利用控制器提供的应用编程接口，网络人员能够灵活地编写多种网络应用，如路由、多播、安全、接入控制、带宽管理、流量工程、服务质量等；转发抽象，转发抽象通常称为“南向接口”，SDN控制器通过利用SDN提供的转发平面的网络抽象来构建全局网络视图。
图2-1 SDN架构
SDN特征：
1)控制与转发分离。转发平面由受控转发的设备组成，转发方式以及业务逻辑由运行在分离出去的控制面上的控制应用所控制。
2)控制平面与转发平面之间的开放接口。sDN为控制平面提供开放的网络操作接口，也称为可编程接口。通过这种方式，控制应用只需要关注自身逻辑，而不需要关注底层更多的实现细节。
3)逻辑上的集中控制。逻辑上集中的控制平面可以控制多个转发面设备，也就是控制整个物理网络，因而可以获得全局的网络状态视图，并根据该全局网络状态视图实现对网络的优化控制。
3、OpenFlow网络简介
从2007年提出至今，OpenFlow得到十足的发展，首先，好多设备厂商例如CISCO，Junifer，Toroki，pronto等相继推出支持OpenFlow协议的交换机、路由器、网络接入点等网络设备。同时，OpenFlow协议在全球得到很大的发展应用而不是仅仅局限于科研理论研究，例如OpenFlow已经在美国斯坦福大学、Internet2、日本的JGN2plus以及其他的10-15个科研机构中部署，并将在国家科研骨干网以及其他科研和生产中应用。OpenFlow的国际覆盖已经包括日本、葡萄牙、意大利、西班牙、波兰和瑞典等。
3.1OpenFlow架构
图 3‑1，这是最基本的OpenFlow网络架构图，主要分为三个部分，控制器（controller）、OpenFlow交换机（OpenFlow switch），终端（terminal）。
图3-1 OpenFlow架构
3.1.1控制器（Controller）
OpenFlow实现了数据层和控制层的分离，其中OpenFlow交换机进行数据层的转发，而Controller实现了控制层的功能。
Controller通过OpenFlow 协议与OF交换机的连接，对OF交换机内的流表和流表项的控制，然后数据流通过交换机的时候，通过与交换机内的流表以及流表项的匹配，使交换机完成对数据流的操作。Controller的这一切功能都要通过运行NOX来实现，NOX就像是OpenFlow网络的操作系统。
此外，在NOX上还可以运行Plug-n-serve、OpenRoads以及OpenPipes等应用程序。
Plug-n-Serve通过规定数据传输路径来控制网络以及服务器上的负载，从而使得负载均衡并降低响应时间。
OpenRoads是支持OpenFlow无线网络移动性研究的框架。
OpenPipes可以在网络系统中通过移动每个子模块来测试每个子模块，并可以决定如何划分设计单元。
3.1.2 OpenFlow交换机（OF Switch）
OpenFlow交换机由流表、安全通道和OpenFlow协议三部分组成。图3‑2，OpenFlow 交换机的逻辑结构图。
3.2.1.1流表
在交换机中的每个流表中包含的一组流表项，用来匹配数据包，每组流表项就是一个转发规则。进入交换机的数据包通过查询流表来获得转发的目的端口。流表项由头域（匹配字段）、计数器和操作（指令）组成；其中头域是个十元组，是流表项的标识；计数器用来计数流表项的统计数据；操作标明了与该流表项匹配的数据包应该执行的操作。3.2.1.2 流表项
流表项包含：
匹配字段：对数据包匹配。包括入口端口和数据包匹配，以及由前一个表指定的可选的元数据。
优先级：流表项的匹配次序。
计数器：更新匹配数据包的计数。
流表项可能包含数据包转发到某个端口。这通常是一个物理端口，但它也可能是由交换机定义的一个逻辑端口或通过本规范中定义的一个保留的端口。保留端口可以指定通用的转发行为，如发送到控制器、泛洪、或使用非OpenFlow的方法转发。如“普通”交换机转发处理；而交换机定义的逻辑端口，可以指定链路汇聚组，隧道或环回接口。
3.2.1.3 指令
3.2.1.4 安全通道
连接OpenFlow交换机到控制器的接口。控制器通过这个接口控制和管理交换机，同时控制器接收来自交换机的事件并向交换机发送数据包。交换机和控制器通过安全通道进行通信，而且所有的信息必须按照OpenFlow协议规定的格式来执行。
3.2.1.5 行动
3.2.1.6 行动集
行动集与数据包相关的行动集合，在报文被每个表处理的时候这些行动可以累加，在指令集指导报文退出处理流水线的时候这些行动会被执行。
3.2.1.7 组
组表示一组泛洪的指令集，以及更复杂的转发（如多路径，快速重路由，链路聚合）。作为间接的通用层，组也使多个流表项转发到一个单一的标识符（例如一个共同的下一跳的IP转发）。这种抽象的行为使相同的输出行动非常有效。
3.2.1.8 组表
组表包含组表项，每个组表项包含了一系列依赖于组类型的特定规范的行动存储段。一个或多个操作的行动用来使数据包发送到该组。
3.2.1.9 计量
一个交换机元件，可以测量和控制数据包的速度。当数据包速率或通过计量的字节速率超过预定义的阈值时，计量触发计量带。如果计量带丢弃数据包的功能，它则被称为一个速率限制器。
3.1.3 数据包在交换机中的处理
OpenFlow 交换机具体的实现过程可以通过图3‑3得到直观的展示。
OpenFlow交换机在接收一个数据包时，执行在图 3‑4中所示的功能。交换机开始执行一个查找表中的第0个流表，并基于流水线处理，也可能在其它流表中执行表查找。
数据匹配字段从数据包中提取。用于表查找的数据包匹配字段依赖与数据包类型，这些类型通常包括各种数据包的报头字段，如以太网源地址或IPv4目的地址。除了通过数据包报头中进行匹配，也可以通过入口端口和元数据字段进行匹配。元数据可以用来在一个交换机的不同表里面传递信息。报文匹配字段表示报文的当前状态，如果在前一个表中使用Apply-Actions改变了数据包的报头，那么这些变化也会在数据包匹配字段中反映。
数据包匹配字段中的值用于查找匹配的流表项，然后再通过流表项对数据包进行处理，每个数据包在相应的流表中会有相应的流表项进行处理。如果流表项字段具有值的ANY（字段省略），它就可以匹配包头中的所有可能的值。如果交换机支持任意的的位掩码对特定的匹配字段，这些掩码可以更精确地进行匹配。
数据包与表进行匹配，优先级最高的表项必须被选择，此时与选择流表项相关的计数器也会被更新，选定流表项的指令集也被执行。如果有多个匹配的流表项具有相同的最高的优先级的，所选择的流表项被确定为未定义表项。只有控制器记录器在传统的流信息中没有设置OFPFF_CHECK_OVERLAP位并且增加了重复的表项的时候，这种情况才能出现。
如果在流水线处理前，交换机配置包含OFPC_FRAG_REASM标志，IP碎片必须被重新组装。
当交换机接收到一个格式不正确或损坏的数据包，此版本的规范没有定义预期的行为。
3.2 FlowVisor
3.2.1 Flowvisor综述
网络的虚拟化一直是网络研究组织的研究目标，通过网络的虚拟化，多个逻辑上独立的网络可以共享同样的物理设备。通常情况下，利用利用软件的灵活性和对硬件的复用达到网络虚拟化的效果。研究人员通过不断的研究，提出可以通过对网络进行分片达到网络虚拟化的概念---Flowvisor。
类比于计算机的虚拟化，Flowvisor是处在硬件和软件之间一层虚拟层图 3‑5所示
Flowvisor利用OpenFlow协议对下层网络进行控制，通过OpenFlow协议，控制器（controller）完成对交换机数据包转发的控制。通过分片的机制，Flowsior允许多个控制器控制一台交换机，但是每个控制器只能通过Flowvisor控制某一个虚拟网络（slice）。同时要确保这些虚拟网络（slice）之间以及控制器之间要相互独立。因此通过FlowVisor建立的试验平台可以在不影响商业流的转发速度的情况下，允许多个网络试验在不同的虚拟网络上同时进行。FlowVisor与一般的商用交换机是兼容的，而不需要使用FPGA和网络处理器等可编程硬件。
3.2.2 融合FlowVisor的OpenFlow网络
3.3 OpenFlow的应用
1)OpenFlow在校园网络中的应用。如果我们可以让校园网具有OpenFlow特征，则可以为学生和科研人员实现新协议和新算法提供一个试验平台。OpenFlow网络试验平台不仅更接近真实网络的复杂度，实验效果更好，而且可以节约实验费用。现在已经有包括斯坦福大学在内的几所高校部署了OpenFlow交换机，取得了很好的实验效果。OpenFlow在广域网和移动网络中的应用。
2)在广域网和移动网络中添加具有OpenFlow特征的节点，将带来众多的好处。例如，可以使得固网和移动网络实现无缝控制、使得VPN的管理更加灵活等。NEC 已经利用OpenFlow控制技术对快速、宽带的移动网络进行高效、灵活的网络管理，并解决了两个课题。首先，在多个移动通信方式实现动态切换。在移动通信混杂时以及通信环境恶化时，动态切换通信方式，将满足通信服务所需的服务品质，提供给终端用户。其次，移动回环网络的节能。在一天当中通信量相对较少的夜晚时段，可以汇集网络路径，关闭多余的中转基站的电源，从而节省能源。
3)OpenFlow在数据中心网络中的应用。在数据中心网络中使用OpenFlow交换机，可以使得网络和计算资源更加紧密的联系起来并实现有效的控制。数据中心的数据流量很大，如果不能合理分配传输路径很容易造成数据拥塞，从而影响数据中心的高效运行。若在数据中心网络中添加OpenFlow交换机，则可以实现路径优化以及负载均衡，从而使得数据交换更加迅速。OpenFlow在网络管理和安全控制中的应用。如果网络是基于OpenFlow技术实现的，则经过OpenFlow交换机的每个新的数据流都必须由控制器来做出转发决定。
4)在控制器中可以对这些流按照预先制定的规则进行检查，然后由控制器指定数据流的传输路径以及流的处理策略，从而更好的控制网络。更为重要的是，在内部网络和外网的连接处应用OpenFlow交换机可以通过更改数据流的路径以及拒绝某些数据流来增强企业内网的安全性。
5)基于OpenFlow实现SDN（Software DefinedNetwork）。在SDN中，交换设备的数据转发层和控制层是分离的，因此网络协议和交换策略的升级只需要改动控制层。OpenFlow在OpenFlow交换机上实现数据转发，而在控制器上实现数据的转发控制，从而实现了数据转发层和控制层的分离。基于OpenFlow实现SDN，则在网络中实现了软硬件的分离以及底层硬件的虚拟化，从而为网络的发展提供了一个良好的发展平台。
4 penFlow版本之间的区别
4.1 OpenFlow Version 1.1
发布时间：2011年2月28日
之前的OpenFlow版本是提供给controller一个表的概念。OpenFlow内部的传输通道可以通过单独的通配符或者是严格的匹配表被映射为多个表，但是这些表通常是逻辑上的一个表。
OpenFlow 1.1 通过多表提供了一个更加灵活的传输通道。使用多表有很多好处。第一，许多硬件内部含有多种表（例如L2表、L3表、多TCAM还回表等），通过这些OpenFlow支持的多表可以提高硬件的效率和灵活性。第二，许多网络部署将数据包(forexample ACL, QoS and routing)的正交处理, 同时，单个规则的交叉作用使得在一个表中的这些处理过程可以创建庞大的规则集。（forcing all those processing in a single table creates huge rulesetdue to the cross product of individual rules, multiple table may decoupleproperly those processing ）。
含有多表的OpenFlow传输通道和之前的版本有很大的不同。新版本提供一系列完整的属性表，通过这些属性表可以支持action的全部匹配和设置。建立一个可以支持所有硬件的版本是非常困难的，因此，OpenFlow 1.1 是一个基于可以映射到硬件的类的和可变的通信信道。所有的表都支持的一些局限的表的功能是可以加进去的。
数据包是在流水线中传输的，数据包首先是匹配第一个表然后才可以和其他的表进行匹配。在数据包经过流水线的过程中，会被加上一个action set 、cumulating action 和一个a generic metadata register ，action set是在流水线的最后被分解掉并且被应用到数据包的，metadata可以被匹配到每一个表并且可以在表之间携带状态信息。
这个版本加入对pipeline过程的控制指令。相比于之前的action直接应用到流上，version1.1是将action封装在指令（instruction）中，指令可以在表之间应用这些action，同时可以进行指令的操作，可以直接是数据包调到另一个表（table）上进行执行。
l 交换机可以提供支持多表的流水线（pipeline）“
l 流入口具有可以控制流水线（pipeline）过程的指令
l 控制器可以通过goto指令进行表的数据包遍历
l 在表上可以设置或者匹配元数据区域（Metadata field） (64 bits)
l 包动作可以融合在包动作设置中
l 包动作设置在流水线（pipeline）的尾部执行
l 包动作可以在两个表平台之间应用
l 处理Table- miss动作时可以发给控制器、继续传给下一个表或者丢弃
l 基本的表功能和配置
2、组
新的组概念允许OpenFlow定义一系列端口，这些端口可以作为一个单独的实体用于数据包的转发。这个版本中允许多种类型的组用于定义不同的概念，例如多播、多路径等。每个组包含多个组桶（group buckets），每个组桶又包含一系列应用与数据包在转发到端口前的动作（actions）。组桶同时可以转发到其他的组或者是将组进行链接。
l 组间接代表一系列端口
l 组表具有以下四种类型：
ü ALL -用于组播或者是广播
ü SELECT -用于多路径（multipath）
ü Indirect -简单的间接
ü 快速恢复（Fast Failover） -使用第一个存活端口（live port）
l Group action todirect a flow to a group
l Group bucketscontains actions related to the individual port
3、标签：MPLS&VLAN
之前的OpenFlow版本只支持有限的VLAN服务，只支持带有模糊语义(ambiguoussemantic )标签这一种水平的VLAN。新的标签支持已经添加很多新的动作：添加、修改、删除VLAN标签，同时也支持多种水平的标签，在MPLS shim headers也增加了类似的标签支持。
l 支持VLAN和QinQ添加、修改、删除VLAN头部
l 支持MPLS添加、删除、修改MPLS shim headers
4、虚拟端口
V1.0定义所有的OpenFlow端口都是物理端口，新版本支持虚拟端口，可以用于复杂的转发定义，例如LAGs or tunnels 。
l 支持32bit的端口数量的定义
l 支持交换机将端口定义成虚拟端口
l 为了report虚拟端口和物理端口，增大packet-in包
5、支持controllerconnection failure
之前的版本包括应急流缓存（emergency flow cache）用于处理和控制器之间的连接丢失问题.而在V1.1中，由于缺乏应用性、实施的复杂性以及其他的一些语法上的问题，这种设计被删除了。
在这个版本中添加了两种类似的方法用于处理交换机和控制器连接丢失的问题。. 在fail secure模式中, 交换机继续运行在OpenFlow模式上，直到重新连接到控制器上. 在fail standalone模式上，交换机回到普通处理模式上(Ethernetswitching).
l 删除应急流缓存（Emergency FlowCache ）
l 连接中断就会触发两种模式（fail secure或者fail standalonemode）
6、其他的改变
l 移除802.1d协议
l CookieEnhancements Proposal - cookie mask for filtering
l 设置队列动作（unbundled fromoutput port action ）
l Maskable DL andNW address match fields
l Add TTLdecrement, set and copy actions for IPv4 and MPLS
l 支持SCTP header的匹配和重写
l 支持设置 ECN 动作
l Define messagehandling : no loss, may reorder if no barrier
l 将 VENDOR APIs 重命名为 EXPERIMENTERAPIs
l 对许多其他的漏洞进行修改、重述和澄清
4.2 OpenFlow Version 1.2
Please refers tothe bug tracking ID for more details on each change
发布时间：2011年12月5日
1、支持可扩展匹配（Extensible matchsupport）
之前的版本使用固定长度的结构指定ofp_match，这就阻止匹配过程的灵活性以及新的匹配域的添加。在V1.2中ofp_match被设计成OpenFlowExtensible Match (OXM)的TLV结构，这种结构很好的展现了匹配的灵活性。
重组后的匹配域有很大的改观。之前静态的结构使很多域出现超载的情况，例如tcp.src_port,udp.src_port, 和 icmp.code这些都使用同一个域入口。新版本中所有的额逻辑域都有自己独立的类型。
OpenFlowExtensible Match的特点：
l 使用可变TLV结构OXM（EXT-1）
l 支持灵活的匹配表达和灵活的比特掩码(EXT-1)
l 必要的确定匹配的一致性的系统（EXT-1）
l 为每一个匹配域都分配一个特有的类型，防止超载(EXT-1)
l VLAN的匹配更加灵活(EXT-26)
l 提供运营商级别和研究性的匹配(EXT-42)
l 允许交换机拒绝匹配要求
2、Extensible ’set field’ packet rewritingsupport
之前的版本使用手动的动作重新写入头域，而Extensibleset_field action 再次使用OXM 的编程能力定义匹配域，并且允许在单独的动作上重新写入任何头域（EXT-13）。这就允许包括experimenter域在内的任何新的匹配域被重新写入。这就使这个版本更加清晰并且降低了产生新的匹配域的开销。
l Deprecate mostheader rewrite actions
l Introduce genericset-field action (EXT-13)
l Reuse match TLVstructure (OXM) in set-field action
3、对packet-in 数据包有更加全面的表述
The packet-in message did include some of thepacket context (ingress port), but not all (metadata), preventing thecontroller from figuring how match did happen in the table and which flowentries would match or not match. Rather than introduce a hard coded field inthe packet-in message, the flexible OXM encoding is used to carry packetcontext.
l 在packet-in中再次使用TLV结构（OXM）描述metadata
l 在packet-in结构中包含metadata结构
l 将入端口和物理端口从静态转变成OXM编程模式
l 在TLV结构中允许随意添加包头
4、通过experimentererror扩展检错数据包
An experimenter error code has been added,enabling experimenter functionality to generate custom error messages (EXT-2).The format is identical to other experimenter APIs.
5、支持IPV6
通过灵活的匹配添加了IPV6匹配和头部重写
l 在IPV6源地址、目的地址、协议号、traffic class，ICMPv6 type,ICMPv6 code 和IPV6邻居发现协议的头部添加了匹配域（EXT1）
l 在IPV6流标签中（EXT-36）添加匹配
6、简化了流模式请求的行为（EXT-30）
l MODIFY and MODIFYSTRICT commands never insert new flows in the table
l New flag OFPFFRESET COUNTS to control counter reset
l Remove quirkybehaviour for cookie field.
7、包解析协议被去除
OpenFlow协议没有包解析协议（EXT-3），这个匹配域仅仅在逻辑上被定义。
l OpenFlow协议不再对数据包进行解析
l 通过OXM pre-requisite达到数据包解析的效果
8、控制器角色转变机制
这种机制就类似于为了支持failover而设置的支持多控制器的机制（EXT-39）。这个机制中完全由控制器进行控制，交换机只是记住每个控制器的角色然后帮助控制器选择机制。
l 为了failover支持多控制器
l 交换机可以同时连接多个控制器
l 支持每个控制器在equal, master 或者slave这三个角色之间进行转变
9、其他的改变
l Per-tablemetadata bitmask capabilities (EXT-34)
l Rudimentary groupcapabilities (EXT-61)
l Add hard timeoutinfo in flow-removed messages (OFP-283)
l Add ability forcontroller to detect STP support(OFP-285)
l Turn off packetbuffering with OFPCML NO BUFFER (EXT-45)
l Added ability toquery all queues (EXT-15)
l Addedexperimenter queue property (EXT-16)
l Added max-rate queue property (EXT-21)
l Enable deletingflow in all tables (EXT-10)
l Enable switch tocheck chaining when deleting groups (EXT-12)
l Enable controllerto disable buffering (EXT-45)
l Virtual portsrenamed logical ports (EXT-78)
l New errormessages (EXT-1, EXT-2, EXT-12, EXT-13, EXT-39, EXT-74 and EXT-82)
l Include releasenotes into the specification document
l 对许多其他的漏洞进行修改、重述和澄清
4.3 OpenFlow version 1.3
发布时间：2012年4月13日
Please refers tothe bug tracking ID for more details on each change
1、重构能力协商
在之前的版本中，交换机的能力是有限的，而在OpenFlow 1.3中对于能力的表述具有一个很大的灵活性（EXT-123）。
以下是重构能力协商的特点的介绍：
l 将’stats’ 框架重命名进’multipart’ 框架
l 允许’multipart’ 请求(requestsspanning multiple messages)
l 将端口列表描述移动到multipartrequest/reply
l 将表能力移动到multipartrequest/reply
l 创建灵活的性能结构表述表能力
l 可以表达experimentercapabilities
l 对table-miss flowentries 添加部分能力
l 添加goto能力
2、对table miss有更加灵活的支持
在之前的版本中，通过表控制标签选择三种行为中的一种来处理table
Miss(如果数据包和任何流都匹配)。而在OpenFlow V 1.3中使用table miss流入口代替原来的标签对table miss进行处理（EXT-108）。
Table miss 流入口使用标准的流指令和动作对table miss数据包进行处理，这就是我们在处理那些数据包的时候，可以充分利用OpenFlow协议带来的灵活性。不仅通过标签的形式所表达的对Table miss进行的处理，都可以通过使用table miss流入口进行满足。而且增加许多新的对table miss数据包的处理，例如table-miss withnormal处理。
l 移除table -miss处理标签（EXT-108）
l 定义table- miss流入口作为所有的通配符和最低优先级流入口（EXT-108）
l 支持table- miss流入口在每一个表中对table- miss数据包进行处理（EXT-108）
l 增加表述table-miss flowentry的能力
l 将table-miss的默认处理是丢弃数据包
3、IPV6扩展头处理
增加对IPV6扩展头和在IPV6头部中一些不规则情况的匹配处理能力。
新的OXM pseudo header fieldOXM_OF_IPV6_EXTHDR可以对IPV6头部进行下列的处理：
l 提出逐跳（逐路由）的IPV6扩展头
l 提出路由器IPV6扩展头
l 提出碎片（fragmentation）IPV6扩展头
l 提出目的地选择的IPV6扩展头
l 提出带有认证的IPV6扩展头
l 提出带有加密的安全开销的IPV6扩展头
l 提出不包含下一个头部的IPV6扩展头
l 提出IPV6扩展头不适用优先级顺序
l 提出Unexpected IPv6extension header encountered.
4、Per flow meters
OpenFlow 1.3增加支持per-flow meters的功能（EXT-14）。rate of packets可以添加在流入口上，并且可以衡量和控制包率（rate of packets）。其中一个重要的额应用就是在发送给控制器的rate limitpackets 上。per-flow meters的最大的特点就是基于新的metres框架，这种框架通过使用multiple meteringbands, metering statistics and capabilities 来表达复杂的meters。
当前，只用简单点rate-limiter meters 在这个框架中被定义。对于meters的更加广阔的应用还有待于进一步的提出。
l 基于per-flow metersand meter bands 的灵活的meter 框架
l 包括per bandstatistics的Meter statistics
l 将meters灵活的添加进流入口
l 当前支持简单的rate-limiter（丢包）
5、Per connectionevent filtering
之前的版本表述让一个交换机同时连接多个控制器用于容错和负载均衡。Per connectionevent filtering 是通过过滤掉控制器不想执行的交换机的请求（EXT-120）。
在OpenFlow message上添加一个新的设置用于在控制器和交换机之间连接的时候进行配置一个event filter。异步信息可以通过type and reason 进行过滤。并且每个控制器都有一个备份滤波器用于slave、master、equal角色。
l 在控制器的连接上添加异步滤波器
l Controllermessage to set/get the asynchronous message filter
l 设置默认滤波器值用于匹配OpenFlow 1.2behaviour
l 删除OFPC_INVALID_TTL_TO_CONTROLLER控制标签
6、Auxiliaryconnections
在之前的版本中，控制器和交换机之间的连接只允许用TCP协议连接，这就使得对大多数交换机实现上面的平行需求（parallelismavailable ）的研究产生很大限制。OpenFlow 1.3 允许交换机建立和控制器之间的辅助性连接来支持他们之间的主要连接（EXT-144）。辅助连接大部分是在运送packet-in和packet-out信息的时候运用。
l 允许交换机和控制器之间建立辅助连接
l 授权辅助连接和主链接共存
l 在协议中添加auxiliary-id 用于区分连接类型之间的区别
l 在UDP和DTLS上也允许建立辅助连接
7、MPLS BoS matching
一种新的OXM域OXM_OF_MPLS_BOS用于匹配MPLS头部的BOS（Bottom of Stack ）bit（EXT-85）。BoS bit 作用是如果其他的MPLS shim header 在当前的MPLS报的开销中，并且和BoS bit匹配，那么，这种bit就可以用于消除where the MPLSlabel is reused across levels of MPLS encapsulation 之间的区别。
8、Provider BackboneBridging tagging
支持通过使用Provider Backbone Bridging(PBB) 封装给数据包加标签，这就使得OpenFlow可以支持多种基于PBB的网络调度和部署，例如regular PBB andPBB-TE 。
l Push and Popoperation to add PBB header as a tag
l New OXM field tomatch I-SID for the PBB header
9、Rework tag order
在之前的版本中，数据包的标签顺序是静态的。例如，MPLS shim header 通常被加在数据包中所有的VLAN标签的后面。在OpenFlow 1.3中就去除这种限制，数据包中国标签的最后顺序是通过标签操作实现的，每一个标签操作通过最外面的位置添加自己的标签(EXT-121) 。
l 移除静态的标签顺序的规定
l 现在标签是在outermostpossible position添加的
l 动作列表（Action-list ） 可以任意顺序添加标签
l Tag order ispredefined for tagging in the action-set
10、Tunnel-IDmetadata
逻辑端口概念使OpenFlow可以支持多种封装。tunnel-idmetadata OXM_OF_TUNNEL_ID 就是一个新的OXM field that expose to the OpenFlow pipelinemetadata associated with the logical port, most commonly the demultiplexingfield from the encapsulation header (EXT-107) 。
例如，如果逻辑端口执行GRE封装，tunnel-id field 就会映射到GRE头部的GRE key。解除封装后，OpenFlow可以匹配tunnel-id 匹配域的GRE key。类似地，通过设置tunnel-id ，OpenFlow可以在被封装的数据包中设置tunnel-id 。
11、Cookies inpacket-in
cookie field 是在packet-in 添加的（EXT-7）。这个field从发送给控制器的数据包的流中获得所需的值。如果这个数据包不是从流中发送的，那么这个域就被设置成0xffffffffffffffff。
packet-in 中的Cookies使控制器更加高效的分类packet-in信息，而不是通过全部的流表匹配数据包。
12、Duration forstats
在大多数的统计中都使用duration field ，包括port statistics,group statistics, queue statistics and meter statistics （EXT-102）。Duration field 使packet and byterate from the counters included in those statistics 得计算更加精确。
12、On demand flowcounters
在disable packet and bytecounters on a per-flow basis 中添加新的flow-mod 标签。使这些计数器失去能力，可以提高交换机的流处理表现能力。
13、Other changes
l 修改一个关于VLAN匹配的漏洞
l 流入口描述（Flow entry description）引入优先级的设置 (EXT-115)
l 流入口描述（Flow entry description）引入timeout andcookies (EXT-147)
l 不可利用的计数器（Unavailablecounters）必须设置成全 1的形式 (EXT-130)
l Correctly referto flow entry instead of rule (EXT-132)
l 对许多其他的漏洞进行修改、重述和澄清
4.4 区别综述
V1.1版本中增加对多级表、群组表、标签以及虚端口等特性的支持；V1.2版本增加对IPv6以及可扩展匹配的支持；V1.3版本规范了基于参数类型、长度和数值(TLV)的能力表达框架，还增加了对逐流计量以及IPv6扩展头处理等功能的支持。
5 SDN/OpenFlow发展
5.1 学术研究组织
5.1.1 ONF
2011年，在雅虎、Google、德国电信等几家公司的倡议下，开放网络基金会（Open NetworkingFoundation，ONF）成立，其致力于软件定义网络及OpenFlow技术的标准化（规范制定）以及商业化，也是目前最为活跃的SDN标准化组织。
该组织主要关注SDN及OpenFlow技术的标准化（规范制定）以及商业化。目前，ONF由董事会成员及会员两部分组成。董事会成员主要包括部分运营商、互联网及软件公司，包括德国电信、日本NTT、Facebook、Google、微软、Verizon、雅虎以及高盛等8家成员；会员则包括网络设备商、网络运营商、服务器虚拟化厂商、网络虚拟化厂商、测试仪表厂商等在内的80多家成员。
2012年，SDN成为全球网络界最炙手可热的焦点，ONF创始至今，已经为设备和软件提供商、服务提供商及电信运营商带来众多机遇。因此ONF成员数量也快速扩张。ONF成员也在不同领域开展了SDN的技术研究和部署。国内运营商中的中国移动已经成为ONF组织的成员，而中国电信也在积极申请中。
ONF组织架构如图2所示，其中技术工作组是其主要的技术研究部门，包括扩展性组、配置和管理组、测试和互操作组、迁移组、市场培育组、结构框架组、转发抽象组和光传输组等8个子工作组，此外，ONF设置有5个讨论组，分别是专题讨论组、无线传输组、安全组，技能验证组和日本组。
目前ONF最主要研究成果是OpenFlow标准和OpenFlow-CONFIG标准（即OpenFlow配置和管理协议）。OpenFlow协议用来描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。各版本OpenFlow标准及其相应特点如表1所示。
OpenFlow配置和管理协议（OF-CONFIG）由配置和管理工作组制定和维护，是OpenFlow协议的同伴协议，是在包含OpenFlow交换机的运营环境下，除OpenFlow协议之外的接口配置和管理协议规范，目前采用NETCONF协议进行传输。
5.1.2 IETF
IETF成立于1985年底，是全球互联网最具权威的技术标准化组织，主要任务是负责互联网相关技术规范的研发和制定，当前绝大多数国际互联网技术标准出自IETF。与ONF相比较，IETF更多是由网络设备厂商主导，聚焦于SDN相关功能和技术如何在网络中实现的细节上。
IETF早期有两个与SDN相关的研究项目/工作组，分别是转发与控制分离组（ForCES，forwarding and control elementseparation）和应用层流量优化工作组（ALTO，application-layer trafficoptimization）。其中，ForCES已经发布了9个RFC，主要涉及需求、框架、协议、转发单元模型、MIB等；ALTO主要通过为应用层提供更多的网络信息，完成应用层的流量优化，用于判断的参数包括最大带宽、最少跨域、最低成本等等。ALTO的研究思想体现了SDN向上层应用开放接口的理念，这种开放部分网络信息以优化应用的做法，从广义上讲也是SDN的一种实现类型。
此外，IETF还着手制定I2RS标准。I2RS的核心思想是在目前传统网络设备的路由及转发系统基础上开放新的接口来与外部控制层通信，外部控制层通过设备反馈的事件、拓扑变化、流量统计等信息来动态地下发路由状态、策略等到各个设备上去。可以看出，I2RS延用了传统网络设备中正在使用的路由、转发等结构与功能，并在此基础上进行功能的扩展与丰富。
目前，IETF 也以软件驱动网络（softwaredriven network）为出发点研究SDN，成立了SDN BOF，并提出了IETF定义的SDN架构，如图3所示。
ONF中的OpenFlow协议强调的是设备控制与转发分离，以实现转发设备的标准化和开放化。而IETF中定义的SDN网络架构重点强调的是设备的可编程性，即开放北向API接口，为用户创新提供有力保证。
5.1.3 ITU-T
ITU-T也在近期开展了对SDN的相关研究。通过与ONF的联络协商，ITU-T明确了将针对运营商网络进行SDN场景对象、相关架构的研究。
在2013年2月的SG13（Future networks including cloud computing, mobile andnext-generation networks）全会上，将原有的28个Question重组为19个Question，并对SDN强相关的Question进行了重命名。其中，承接上一研究期，修改Q14在研项目Y.FNsdn研究范围从而覆盖SDN定义、总体特征、功能需求和架构。图4示出了Y.FNsdn标准中所定义的SDN 框架。
SG 13主要面向SDN功能需求和网络架构的标准化，而SG 11则结合SG 13的工作，开展SDN信令需求和协议的标准化。2013年2月在日内瓦召开的SG 11全会上，确定了以下几个方向的研究议题。
软件定义的宽带接入网（SBAN）应用场景及信令需求（Q.SBAN）；SDN的信令架构（Q.Supplement-SDN）；基于宽带网关的灵活网络业务组合信令需求（Q.SBNG）；跨层优化的接口和信令需求（Q.CSO）；支持IPv6的标准化智能可编程接口应用场景及信令需求（Q.IPv6UIP）。
与此同时，2013年2月SG15 Q12/Q14的中间会议也开始研究SDN对传送网络架构的影响，并根据会议提交的多篇文稿制定了SDN在传送网方面的Living List，这些研究点将会是SG15 Q12/Q14后续SDN研究的重点。
5.1.4 ETSI
国际主流运营商发起成立了网络功能虚拟化行业规范工作组(NFV ISG)并于2013年1月召开了第一次会议。本工作组将制定支持虚拟功能硬件和软件基础设施的要求和架构规范以及发展网络功能的指南。工作组的工作将视情况整合现有的虚拟化技术和标准，并与其他标准委员会正在开展的工作相配合。
NFV 和SDN 是互补的，但又不相互依赖。虽然二者的结合可能产生更高的价值，但NFV 的实现可以不使用SDN。
5.1.5 CCSA
CCSA已开始在TC1和TC3设立SDN研究任务，预研SDN的应用场景/需求和问题分析、术语及定义、系统架构和功能模型、设备技术规范、互通规范和测试规范等。
2012年8月，TC1召开了“未来网络与SDN”专题研讨会，主要对SDN应用及发展，架构及关键技术进行了讨论。2013年1月，TC1成立了“未来数据网络（FDN）”特别工作组，分别在应用场景、功能架构、接口协议方面专门立项开展研究。2012年12月，TC6 WG1（传输工作组）针对“软件定义光网络技术”进行了研究立项，该项目将针对光网络的需求和特点，提出面向光传送网的SDN关键技术和解决方案。
5.2 技术实现方面
5.2.1 Nicira公司
2007年，Martin Casado博士联合Nick McKeown、Scott Shenker教授（加州大学伯克利分校），共同创建了致力于网络虚拟化的Nicira公司，并最先提出了SDN的概念。
由Nicira开发出的OpenvSwitch是一个具有产品级质量的多层虚拟交换机。图 6‑1通过可编程扩展，可以实现大规模网络的自动化（配置、管理、维护）。它支持现有标准管理接口和协议（比如netFlow，sFlow，SPAN，RSPAN，CLI，LACP，802.1ag等，熟悉物理网络维护的管理员可以毫不费力地通过Open vSwitch转向虚拟网络管理）。
Open vSwitch是一个由Nicira Networks主导的开源项目，通过运行在虚拟化平台上的虚拟交换机，为本台物理机上的VM提供二层网络接入，跟云中的其它物理交换机一样工作在Layer 2层。Open vSwitch充分考虑了在不同虚拟化平台间的移植性，采用平台无关的C语言开发。
OVS具备很强的灵活性。可以在管理程序中作为软件switch运行，也可以直接部署到硬件设备上作为控制层。同时在Linux上支持内核态（性能高）、用户态（灵活）。此外OVS还支持多种标准的管理接口，如Netlow、sFlow、RSPAN、ERSPAN、CLI。对于其他的虚拟交换机设备如VMware的vNetwork分布式交换机跟思科Nexus 1000V虚拟交换机等它也提供了较好的支持。
其主要特性包括：
虚拟机间互联的可视性；支持trunking的标准802.1Q VLAN模块；细粒度的QoS；每虚拟机端口的流量策略；负载均衡支持OpenFlow；远程配置兼容Linux 桥接模块代码。
2013年Nicira公司已经被VMware收购。
5.2.2 BigSwitch Networks
除了Nicira 之外，Big SwitchNetworks 可能算是最知名和最好的新兴SDN初创公司，该公司支持OpenFlow 协议，并且该公司准备推出其控制器软件Floodlight 的商业版本，这吸引了一些知名企业高管的关注。大多数行业专家们都认为Big Switch 将被该行业的一线企业收购，IBM 可能是潜在的收购方，鉴于IBM 开始专注于数据中心融合，并且已经与Big Switch合作了开放数据中心互操作网络(ODIN)等项目。
为了加快对软件定义网络的OpenFlow的部署，Big Switch推出了开源的“瘦”虚拟交换机Switch Light，用于服务器和商业交换机。Switch Light是可以部署在服务器管理程序和基于商业芯片的物理交换机中的软件，该软件的目的是为用户提供供应商专有网络架构的替代品，以及加速OpenFlow(流行的SDN API和协议)的部署。Big Switch称Switch Light为企业提供了网络硬件选择，这将有助于降低成本，同时，它通过共同的配置和管理模式合并虚拟和物理网络，帮助减少运营成本。这种管理和配置模式可以通过单独的OpenFlow控制器来实现， Switch Light基本上负责管理代理的职责。
5.2.3 Insieme Networks
InsiemeNetworks公司将开发可以支持整个数据中心大型结构控制器，其中包括网络、4~7层服务、存储和计算。这项技术将使用一种通用的策略操作模型，它有一个统一API，并且支持一些标准接口，如JSON和XML。
这个战略将使企业应用开发团队和基础架构团队理解各自的需求，然后通过网络编程自动交付。这个方法听起来与SDN新创公司Plexxi用其Affinity Networking技术开发的产品相似。Insieme将为应用开发者提供定义针对应用的基础架构连接需求的视图和功能。它们定义了应用及其向基础架构交付的服务。它就像UCS的服务配置文件概念。在定义之后，它就能够在整个基础架构中自动运行，因此无论应用程序在什么位置，都将符合这个应用配置文件。
5.2.4 IBM
目前，作为专门负责 OpenFlow 标准和规范的维护及发展的开放网络基金会（OpenNetworking Foundation）已经拥有包括包括 Google、Facebook、Yahoo等 6 位理事会成员和包括 IBM、HP、Cisco、Juniper 、NEC以及国内的华为和中兴等主流网络设备制造商近 50 位成员。除了主流网络设备制造商的支持，Google 和Facebook 也纷纷宣布在其数据中心中成功应用了 OpenFlow/SDN 的技术。IBM 始终是 OpenFlow 标准制定的支持者和积极推动者。2011 年在拉斯维加斯的 Interop 峰会上，IBM 联合NEC 一起发布了基于 OpenFlow 的解决方案，这款新型 OpenFlow 交换机 - IBM 1.28 Tbps RackSwitch G8264，它具有 48 个 SFP/SFP+ 10 GbE 端口和 4 个 QSFP 40 GbE 端口，且可以划分为另外 16 个 10 GbE 端口，支持 OpenFlow 1.0.0，及最多97,000 个流实体，支持 NEC 的pFlow 控制器。图 5‑2所示。
5-2 IBM 1.28 Tbps RackSwitch G8264
5.2.5 华为
华为基于云计算和SDN的全新网络架构SoftCOM，将借助SDN的优势改变运营商的网络和运营管理方式，帮助运营商应对挑战、提升竞争力。协助运营商共同建设端到端的“动态、可扩展、自动化、高效、开放”的下一代网络，助力运营商实现网络、运营和商业方面的转型，构建开放生态系统，同时架构性提高网络利用率和运营效率，结构性降低成本，从而构筑面向未来的竞争力。华为预计在2014年进行商业性试验并且在2015年实现商业性部署。
华为面向运营商的SoftCOM战略
华为提出SoftCOM战略，致力于帮助运营商建立一个完整系统的网络架构。华为表示相比传统的封闭的，复杂的和以控制为主的通信架构，新一代的通信网络是开放，简单和以使能为主的。这样的网络可以通过分开控制和数据面的SDN技术，诸如会晤边界控制器SBC等网络元素的虚拟化，支持云业务的数据中心内的OSS和BSS功能，大规模部署云业务等来实现。
华为表示整个网络的分布式的云/寄宿(hostling)体制将是未来网络的架构。这些技术和架构将会最小化运营商的设备投资成本，降低网络运营复杂性，提高网络效率和灵活性，大大加快新业务推出的进度。
透过华为提出的Carrier SDN技术构架，其面向运营商的SDN构想如下：
弹性：通过设备通用化、处理资源池化、功能多样性、网络可编程，构建弹性而不僵化的网络架构;
简单：通过转发控制分离、网络虚拟化，实现集中管理、简化运维;
敏捷：通过端到端网络资源可抽象、可编程，实现新业务发放简单、快捷;
可增值：通过网络能力开放，使用户获得最佳的网络应用体验，实现网络能力的再增值。
华为面向企业的SDN方案
先来看企业网络面临的难题：底层的网络与上层的业务之间往往是割裂的、分离的;网络对于业务变化的响应缓慢且有限;网络的复杂性导致管理变得不可控了，从而使整体网络和ICT基础设施的效率减低。
华为通过企业SDN解决方案构建起业务友好、高效利用、可视可控的企业ICT基础设施。
首先，华为将SDN架构分为三个层次：网络设备层，网络控制层、业务管理及编排层。其核心理念之一就是全层次开放，能够与不同类型用户的业务需求做到很好的匹配和联动。以互联网企业为例，他们需要的是厂商对于网络设备层的开放，然后基于自身实力进行定制开发，让网络更好的适配现有业务。
其次，云化和融合也是华为企业SDN理念的核心组成部分。华为期望在企业SDN中实现数据中心、园区网、广域网等多个领域的端到端融合;通过对物理网络和虚拟网络的融合控制和管理，实现智能和敏捷的云数据中心。同时，华为认为从现有网络到未来SDN网络是一个平滑演进的改革过程，而不是一场全新的革命。
SDN对外呈现的能力是开放、可编程，其核心支撑技术是网络设备的软硬件灵活性。没有可在线重塑的软硬件能力，就无法充分体现网络对外的开放、可编程价值。5.3 协议应用
2012年，Google宣布已经在其全球各地的数据中心骨干网络中大规模地使用0penFlow／SDN。最近，Facebook也宣布在其数据中心中使用了0penFlow/SDN技术。
下面就具体介绍OpenFlow/SDN在Google数据中心骨干网上的应用
Google的部署分为三个阶段，第一阶段是2010年春天完成的，把Openflow交换机引入到网络里面，但是这个时候Openflow交换机对同网络中的其它非Openflow设备表项的就像是传统交换机一样，只是网络协议都是在controller上完成的，外部行为来看表现的仍然像传统网络。第二阶段是到2011年中完成，这个阶段引入更多流量到Openflow网络中，并且开始引入SDN管理，让网络开始向SDN网络演变。第三个阶段在2012年初完成，整个WANbackbone网络完全切换到了Openflow网络，引入了TrafficEngineering，完全靠Openflow来规划流量路径，对网络流量进行极大的优化。谷歌使用Openflow，最主要做的就是TrafficeEngineering，优化转发路径，其它的相对次要。
谷歌称自己的SDN网络为B4。下面就是谷歌B4网络的混合式迁移分三步走：
Google的网络架构是传统的SDN的架构，使用集中化controller，controller之上运行了很多application，包括一些标准网络协议，他们明确提到的包括OSFP,BGP,ISIS，这些路由协议都来自于开源的quagga协议栈(也就是商业协议栈ZebOS的前身，现在仍在维护中)。
在图 5‑6，我们可以看到谷歌已经部署了几套网络控制器服务器(NCS)以及交换机。这些NCS包含为各种网络要素提取的控制层。这些交换机运行了一个OpenFlow代理，Vahdat解释到，这种基本的控制是基于所有事件都运行于外部服务器的一套控制器上，且需要处于同一位置，而这些NCS都使用32核服务器。
在这些NCS之上，有运行首项选择的OpenFlow控制器，用于高可用的故障转移。主要应用是一个流量工程应用，可以把策略实例化为控制协议，包括BGP，ISIS和OpenFlow。
Google总结说：
“Openflowisreadyforreal-worlduse.SDNisreadyforreal-worlduse.Google的数据中心WAN网络已经成功地基于Openflow搭建起来了。”
文章很长，未完待续。。。
1483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
