OpenFlow

1 简介

OpenFlow® is the first standard communications interface defined between the control and forwarding layers of an SDN architecture. OpenFlow® allows direct access to and manipulation of the forwarding plane of network devices such as switches and routers, both physical and virtual (hypervisor-based).

OpenFlow-based SDN technologies enable IT to address the high-bandwidth, dynamic nature of today's applications, adapt the network to ever-changing business needs, and significantly reduce operations and management complexity.

For historical information about the origins of OpenFlow® at Stanford University prior to the creation of ONF, please see archive.openflow.org.

官网：https://www.opennetworking.org/sdn-resources/openflow

2 协议1.3

文档：openflow-spec-v1.3.pdf

其它最新文档下载：https://www.opennetworking.org/technical-communities/areas/specification

总结：

图1

图2

图3

图4

OpenFlow协议（OVS）: http://www.cnblogs.com/liangan/p/5589214.html

OpenFlow1.3协议解析: http://blog.csdn.net/sherkyoung/article/details/44098497

参考：http://www.cnblogs.com/qq952693358/p/5841186.html

SDN原理 OpenFlow协议 -1

本文基于SDN原理视频而成：SDN原理

OpenFlow

OpenFlow 协议 和 传统的路由选择协议 有很多相似的地方，同时在某些地方也具有一定的颠覆性。

路由表，由IP地址和子网掩码组成。MAC表，由MAC地址组成。
但是OpenFlow协议的流表，却什么都有。

OpenFlow 相比传统路由协议来说，更大更广泛；是一种推倒重来的做法。

功能

OpenFlow 1.0

OpenFlow 1.3 及 更新的版本

相比1.0，1.3的OpenFlow交换机支持 多流表，多控制器，主表，计量表等等。

主要功能：

• 用于实现 Controller 和 Switch 的通信，定义了一系列的标准术语。
• 定义了 Controller 如何来控制 Switch 以及 Switch 如何来反馈 Controller。
• 定义了 Controller 和 Switch 通信过程中的 消息类型和格式。

发展 版本

流表 FlowTable --- OpenFlow的核心

如果拿传统网络中的技术来类比流表，那么流表就相当于 路由选路中的路由表，交换机中的MAC地址表；有了流表，交换机才能进行转发工作。

传统的路由表，MAC地址表 无法按需更改，不可编程化；现在的OpenFlow协议支持多张流表，一个交换机可能有几张流表，相比传统的交换机，多流表增加了交换机工作的复杂性：什么时候选择什么样的流表。

在SDN网络中，经常会发送的一件事情是，有需要来对流表表项进行修改，或者是当一个数据报经过一个OpenFlow的交换机的时候，能够对它的源/目的IP地址，源/目的MAC地址进行修改，导致它选择不同的路径。传统的流表，无论是静态路由表还是动态路由表均不支持；而SDN网络交换机的流表 需要支持 可修改化，可编程化。

因此，介绍流表，从以下五个方面介绍：

• 流
• 流表
• 流表项
• 流表匹配
• 如何生成流表？

在学习过传统网络之后，学习以上的五个内容，就是一个不断进行 对比 的过程。

问题1：流 Flow

(1)流 一般由网络管理员来进行定义，根据不同的流执行不同的策略。

(2)流：同一时间，经过同一个网络，具有相同属性的数据报集合。

• 这里的相同属性，根据不同的情况，可以不同；比如我们可以定义 目的IP地址相同 的数据报集合为一个流，也可以定义 同一个协议为一个流，或者 同一个源IP地址为一个流。

(3)在SDN网络中，所有的数据都以 流 为基本单位进行处理

目前，一般情况下，我们都以源/目的IP地址，或者是端口号 定义流的相同属性。

问题2：流表 Flow Table

注意：流经过一个交换机之后，最后结果和传统的路由器相类似：转发，或者丢弃。
但是，如果一个交换机同时拥有多张流表，那么比起传统路由器 查完唯一的一张路由表 以外，还有第三种选择：继续查下一张表。

当一个流来到一个运行OpenFlow协议的交换机的时候，开始查表；基于序号的查找：根据表项的序号来进行查找。每一张Table中都有详细的表项。

(1)流表就是交换机的一张转发表；类比于 传统网络路由器的路由表，交换机的MAC地址表/CAM表。

(2)流表由一系列连续的表项(路由条目)组成。

(3)除了OpenFlow1.0版本之外，后续版本中，OpenFlow支持多流表。

问题：目前的OpenFlow支持200+流表，那么比起 传统网络路由器/交换机只需要找一张表 来看 速度肯定会更慢啊？

快和慢是一个相对的概念，传统网络的路由表是仅需要查找一张表，但是它们采用的模式是 ”接力棒模式“ 或者说 分布式交互，路由更新的时间十分缓慢，路由汇聚的时间长；而SDN网络所有的路径选择，生成流表 以及相关的控制措施，都是由控制层来实现的，转发层只负责转发，并不需要生成流表，流表由控制器提供。交换机和交换机之间并不需要多的沟通。
因此，看上去SDN网络交换机的流表更多，需要查找的表项更多，但 整体的时间 是小于 传统交互式网络的路由时间 的。

SDN原理 OpenFlow协议 -2

本文由SDN原理视频而成：SDN原理

流表 FlowTable --- OpenFlow的核心

问题3 流表项 Flow Entry

单流表(OpenFlow 1.0版本) -> 多流表(OpenFlow 1.3版本)

组成1(OpenFlow 1.0)：Header Fields | Counters | Actions

不同版本的OpenFlow协议的流表项 不一样。OpenFlow 1.0版本包括了包头域，计数器，动作三个部分。

流表项包头域 --- 匹配

可以看出来，除了进接口，传统OSI七层模型中2-4层的寻址信息都包含在报头域中了：目的IP地址，源IP地址，目的MAC地址，源MAC地址，端口号···

因此，流表约等于 路由表 + MAC地址表 + 端口号··· 包含了原有OSI七层所有的寻址信息。
也就是说：OpenFlow交换机 相比 传统网络的交换机 是一个比较模糊的概念，不再区分交换和路由；所以 OpenFlow交换机 可以广义理解为 OpenFlow转发设备 (路由器，交换机，防火墙)。

从小的方面来看，SDN交换机是一个传统意义上的OSI二层设备；从大的方面来看，它是一个”具有七层结构“(指的是 具有所有七层寻址信息)的交换机。

有新意的地方：取消了传统网络 中间路由 的分层结构 分层次进行匹配；把所有的信息一次性进行匹配。

计数器 --- 流量可视化

传统网络的计数器这一方面，是一个弱项；虽然TCP有 四个定时器：重传定时器，坚持定时器，2MSL定时器，保活定时器，IP有TTL字段，但是没有比较多的技术支持对数据流进行计数。
也就是说，在传统网络里面，你不知道通过每一个接口的流量具体有多少，在这条链路上已经跑了多少流量。
简单来说，就是流量可视化。

SDN需要支持流量可视化，方便管理人员和用户根据可视化的流量来指定一些策略：比如拥塞控制，提高链路带宽的利用率等等。

计数器 Counters 主要对每张表，每个端口，每个流进行计数：方便监管流量。
比如：经过这个端口已经有多少流量了？匹配这个流表项的数据报有多少了？这个表项 或者这张表 查找多少次了？

如果所有的交换机支持计数器，那么每一个交换机都根据计数器向控制器汇总流量信息，那么控制器就很容易生成一张全局的流量图，方便用户对流量进行监控和制定策略。
这是 SDN 中很核心的一点，很有新意的一点。

Actions 动作 流表项的关键 --- 按需修改

Action 动作 是对匹配该表项的流的操作。

传统网络的动作，就两种：要么进行转发，要么进行丢弃。而SDN中的动作，非常的多。
原因：OpenFlow协议需要支持 源目IP地址，源目MAC地址等等的 按需修改。

OpenFlow 1.0规定了必备动作(Required Actions)，和可选动作(Optional Actions)。

必备行动1 -转发 Forward

• 泛洪选项，ALL -转发到所有出口(但不包括入口)，相当于往所有接口泛洪。
• 给控制器，CONTROLLER -封装并转发给控制器
• 找本地，LOCAL -转发给本地网络栈
• 按表执行，TABLE -对要发出去的包执行流表内的动作
• 从哪里来从哪里去，IN_PORT -从入口发出

必备行动2 -丢弃 Drop

没有明确指明 处理行动 的表项，将匹配的所有分组默认丢弃。

可选行动1 -转发 Forward

• NORMAL -按照传统OSI七层模型中的第二层(源目MAC)，或者是第三层(源目IP)进行转发。
• FLOOD -通过最小生成树从出口泛洪发出，不包括入口。

可选行动2 -入列 Enqueue

将包转发到 绑定某个端口的队列 中去；常用于管道限速。

非常重要的 可选行动3 -修改域 Modify-field

修改报头内容 这是和传统网络最大的区别：OpenFlow能够对报头信息进行修改。

很明显，OpenFlow所提供的流表，表项比传统网络路由表等 更加丰富，操作，执行动作比以前更加繁多。

组成2(OpenFlow 1.3)：Match Fields | Priority | Counters | Instructions | Timeouts | Cookie

在1.3版本中：流表项包头域 -> 匹配域；多了一个 优先级；动作 -> 指令；增加了 超时时间 和 缓存信息。

从1.0版本开始，OpenFlow支持多流表：每张流表都有独立的序号，从序号最小的流表开始匹配，每张表进行独立的处理操作。

匹配域 -匹配

匹配域是之前1.0包头域的拓展，匹配内容除了OSI二到四层的寻址信息(MAC，IP，PORT)之外，多了MPLS，IPv6，PBB，Tunnel ID 等支持；1.0版本能匹配12个信息，1.3版本能够匹配39个信息。

这样做的原因，是为了尽量减小传统网络协议对SDN的影响；如果还有OpenFlow尚未支持的协议，那么就通过混合型网络来支持。当OpenFlow发展到支持匹配所有路由信息的时候，那么就可以摒弃掉原来传统网络路由转发的机制了。

趋势：传统路由选择协议 -> 混合协议(OpenFlow 与 传统路由选择协议 共存) -> OpenFlow协议 SDN时代。

优先级 -优先匹配

顾名思义，用于标志流表项匹配的优先次序，优先级越高 越早匹配，默认为0。

计数器 -流量可视化

和之前类似，主要对 流，表，端口 做统计，方便进行流量监管。
在原有基础上，加入了 每组，每个动作集的计数。

指令(这里只列举部分指令) 是之前动作的抽象 增加了非常多的内容

需要弄明白：动作，动作集，指令。

在新的版本中，指令相比动作增加了非常多的内容，因为引入了多流表的概念，所以多了很多的指令(动作，动作集，指令)。

必备指令：Write-Actions action(s)：将指定的命令添加到命令集中。也就是说，命令不一定要马上执行，可以积累到命令集中，类似一个脚本，然后一起共同执行。
附加指令：Apply-Actions action(s)：立即执行指定的动作，不改变行动集。

在1.3中，命令不一定马上执行：比如Drop，Next Table，Forward等等，它可以直接执行，也可以先 预缓存 到一个动作缓存中(或者说，动作集)。

附加指令：Clear-Actions：在动作集中 立即清除所有的行动。
举个例子，在 流 匹配了多个流表表项之后，通过指令积累了一定的动作，如果感觉到不是特别满意，就可以在下一个流匹配的表项中加入 Clear-Action 这个指令，清除掉之前积累的所有动作。

总的来说，1.3版本的流表项，所支持的逻辑需求 更加丰富。
在1.0版本的时候，动作是一个一个执行的，没办法集中处理；而1.3的话，允许动作集中执行，通过命令形成动作集，或者看这些动作不顺眼，用一个Clean-Actions清空命令集。

注意：

在1.3中，需要清楚的概念是：流表项中有指令Institution和动作Action之分，流表项中的指令 是用于影响动作的：比如通过指令将动作添加到动作集中，或者通过指令清空动作集。
而动作则是一系列对流的操作，比如丢弃，封装之后交给交换机，或者是转递到哪一条链路等等。

这也体现了SDN的一个理念：在原有平面上抽象出一个抽象层，比如我们这里就是从动作中抽象出指令，通过这个抽象层更加方便的进行管理与操作，就像图形界面之于命令行一样。
引用一段话，源自一篇博文SDN：软件定义网络

纵观计算机的发展历程，各方面都可以看到通过增加类似的虚拟化层次来提高生产效率的案例。比如高级语言之于汇编，比如图形界面之于命令行。这种添加层次的解决方案，总是能让问题得到更清晰的解决。

回到指令

在视频教学内，指令分成四块内容：第一块是指令，第二块是动作，它们之间的关系在上面的 注意 已经提及了。
那么第三块，是用来干嘛的呢？

既然，我们使用了第一块的指令，让第二块的动作添加或者是删除到动作集中，目的是为了更好的管理动作；那么当动作需要统一进行的时候，如何确定 动作集中的动作 的先后顺序呢？
比如动作集中 有两个动作添加了进来，一个是将流A封装交给控制器，另外一个是将流B丢弃，哪一个先执行呢？
类比于BGP协议，动态选路确定最优路的时候，有那么多的影响因素，如何确定这些因素影响的优秀级？

指令的第三块内容，就是用来干这个的：它们确定了动作集中动作执行的优先顺序。

指令部分 总结

行动集与每个报文相关，默认为空。

一个流表项可以通过 Clear-Action 和 Write-Action 两个指令来对行动集进行操作。

当一个表项的指令集没有包含 Goto-Table 指令的时候，流水线就停止了(即不用再去查找另外一张流表)，然后报文的行动集就被执行。
注意：多张表的查找，叫做流水线处理。

交换机可以通过 Apply-Actions 修改动作执行顺序。

行动集包括所有的行动，无论它们以什么样的顺序加入到集中，执行的顺序始终按照优先级来进行。

我的理解：流找到对应的表项 -> 表项的指令 将表项的动作添加到动作集中/将动作执行 -> 由表项中的优先顺序(上面的第三部分)确定动作的执行顺序 -> 指令集中没有遇到 Goto-Table指令 按照顺序执行动作集中的动作

也就是说，表项中(1)有指令集，指令集中有 将动作抽象成逻辑层集中处理的指令(Write-Action & Clear-Action) 还有 定义先后顺序的指令；(2)有匹配执行的动作

超时时间 Timeout

用于标志该流表项的 老化时间，到了超时时间限制就删除，目的：节省内存资源。

附属信息 Cookies

由控制器选择的 不透明数据值，控制器使用Cookies来进行 过滤流的统计数据(计数器的相关信息)，流改变，流删除。
但是，当处理单个数据报的时候，不能使用。

SDN原理 OpenFlow协议 -3

问题4：流表匹配

OF1.1版本

这是OF1.1版本的操作，引入了多流表，1.0版本并没有多流表。

• 多流表的匹配称为 流水线处理：交换机从流表0开始查找，按照流表序号从小到大匹配。
• 每个包按照优先级去匹配流表中的表项，优先级高的先进行匹配；一旦匹配成功则刷新计数器和执行动作，倘若没有找到匹配的表项则转发给控制器。

OF1.3版本及之后版本 关键词：叠加执行

OF1.3版本的流表匹配相比OF1.1版本，改变了很多：
(1)当匹配到流表项的时候，首先更新计数器，然后查看指令集(之前有提过，指令是从动作层抽象出来的层次，便于管理动作)，由指令决定动作是立即执行，或者是添加到地址集中；然后查看指令集中是否有 Goto-Table 选项，有的话继续查找下一个表，没有的话执行动作集中的动作。
(2)没有匹配到流表项的时候，查看表内是否有 Table-miss 选项，有的话也查看它的指令集，如果没有直接丢弃。

一个简单的流程：匹配到流表项 -> 看指令集，更新计数器 -> 动作马上执行/加入动作集 -> 查找下一个表/执行动作集；
没有匹配到流表项 -> 有没有 Table-miss 表项 -> 有，查看指令集，接下来和前面的内容类似 / 没有，丢弃。

• 1.3及之后的流表匹配，除了多流表操作之外，引入了 Table-miss 和 Action-set动作集 的处理。
• 之前的版本，当交换机没有匹配到流表项的时候，直接交给控制器处理；那么现在 Table-miss 用于解决 未匹配的流的转发和丢弃问题，通过 Table-miss 的参数，可以对数据流进行转发，丢弃，交给控制器的操作。
• 多流表操作中，每个表都有独立的指令，这些指令(执行动作)可以在查表的时候执行动作，也可以通过指令将动作添加到 Action-set 再叠加执行。

单表时，只有 Action 动作；多表环境中，多个 Action 累积成 action-set；决定 action-set 如何工作的，是表项的指令Instructions：指令可以将动作写入，添加修改到 Action-set 中，也可以直接在读表的时候进行。

至此，流表的问题结束了，那么···

问题来了，如何生成这些表？

传统网络中，在OSPF/BGP/RIP这些路由协议中，是通过分布式的交互来进行路由汇聚，生成表项的，这是动态路由。这是一种P2P架构(双方对等)。
那么，在SDN中，是由控制层的Controller控制器，直接下发流表。

交换机A,B,C,D将链路信息统一告诉Controller，Controller在执行完计算之后，统一下发流表给交换机。
这是一种 Client/Server 架构(C/S架构)。

SDN原理 OpenFlow协议 -4

通道 Channel

在前面的OpenFlow的内容中，我们提到了在交换层所采用的流表是控制层的Controller下发的，那么Controller是如何下发流表的呢？中间经过了哪些的流程和步骤？控制器和交换机的会话是如何建立的？
这就是我们今天要介绍的内容，Channel。

连接建立

Hello包会定期的交换，其中最核心的就是OpenFlow的版本号。

Hello1：Switch -> Controller 你支持版本1.3吗？
Hello2：Controller -> Switch 我支持啊
就像之前的OSPF的Hello报文要交换RID等等的信息一样，比较好理解。

Feature request：Controller -> Switch 你的OF支持哪一些特性？你的接口信息是什么？也就是询问交换机所能提供的功能。
Feature reply：Switch -> Controller 交换机回复一个非常大的包，把它的所有配置信息，所有接口信息都回复给Controller。
Set config：Controller -> Switch Controller下发命令，根据交换机提供的信息对交换机进行简单的设置。

至此，Controller和交换机建立起了一个联系。

packet in：Switch -> Controller 当交换机本地没有匹配到与流相符合的表项 或者说 没有FlowTable(默认)的时候，会将数据包丢给Controller。
packet out：Controller -> Switch Controller回复指示信息，给Switch处理该数据包提供了方法，或者说选择的路径。

port status：Switch -> Controller 当交换机的端口状态发生变化的时候，交换机通知Controller，告诉Controller这个变化，让Controller刷新路径信息。

消息列表

三类消息：

• Controller-to-Switch 消息：有控制器发起，用来管理或者获取Switch状态。例子：上面的 Feature Request 和 packet out。
• asynchronous 消息：由 Switch 发起，用来将网络事件或者交换机状态变化更新到控制器。例子：上面的 port status。
• symmetric 消息：有 Switch 或者 Controller 发起。

第一类消息顾名思义，是由控制器下发到交换机的，比如下发流表。
而第二类消息可以理解为由 交换机向控制器 发送的消息类型，比如端口状态辨认等等。asynchronous直译是 “异步的”。
第三类消息，这类消息是控制器和交换机的 交互，也就是说，既有控制器发送给交换机的消息，也有交换机发送给控制器的消息。symmetric 也就是 “同步的”。典型的第三类消息是Hello报文，你Hello来我Hello过去。

  1、Controller‐to‐Switch
    控制器至交换机消息此类消息由控制器主动发出
　　　 Features 用来获取交换机特性
　　　 Configuration 用来配置Openflow交换机
　　　 Modify‐State 用来修改交换机状态(修改流表)
　　　 Read‐Stats 用来读取交换机状态
　　　 Send‐Packet 用来发送数据包
　　　 Barrier 阻塞消息
　2、Asynchronous
　　 异步消息此类消息由交换机主动发出
　　　 Packet‐in 用来告知控制器交换机接收到数据包
　　　 Flow‐Removed 用来告知控制器交换机流表被删除
　　　 Port‐Status 用来告知控制器交换机端口状态更新
　　　 Error 用来告知控制器交换机发生错误
　3、Symmetric
　　 对称消息，可以由控制器或交换机主动发起
　　　 Hello 用来建立Openflow连接
　　　 Echo 用来确认交换机与控制器之间的连接状态
　　　 Vendor 厂商自定义消息

更进一步的细节，可以参考：OpenFlow消息

协议交互

我们选用的模拟器，首选Mininet，仅使用一条命令 sudo mn 直接就创建了一台控制器，一台交换机，两台电脑的网络拓扑。
甚至，我们可以用Mininet的一条指令，创建一个数据中心！It‘s amazing！

视频教程介绍了传统网络协议和OpenFlow交互的一个案例。
使用 sudo mn 建立一个 含有一个Controller，一个Switch，两个PC的简单网络拓扑。

简单的介绍一下名称：两台PC，h1和h2；连接在h1上的接口eth0；连接在h2上的接口eth0；Switch，S1；在S1上和h1连接的接口eth1；在S1上和h2连接的接口eth2；Controller，简称C；在S1上和C连接的接口L0.

h1想向h2发送一个数据报文，但是不知道MAC地址；传统网络的解决方法是ARP泛洪获知MAC地址，那么在SDN是如何实现的呢？

(1)h1通过ARP协议，向所有接口泛洪ARP请求：报文通过eth1接口来到了S1。
(2)S1不知道这个报文要发到哪里去，并没有合适的表项让它匹配；于是乎，将请求报文转给了控制器：Packet-in消息。
(3)控制器也不知道这个报文要到哪里去(可能是因为刚刚建立连接，还没有建立一个合适的网络拓扑)，于是向交换机S1下发指令，向所有接口(除了eth1)泛洪该数据报：Packet-out消息。
(4)S1向eth2接口发送该ARP请求报文，来到了h2.
(5)