openflow协议简单总结

Openflow 1.3学习

1、组表的深入理解

组表的精髓在于有一系列actions buckets，通过action bucket来完成一系列动作，但不要与action set混淆，action set是动作集，会按一定优先顺序执行，略带僵硬，不好扩展。而action bucket可以优化完成很多任务。组表分为四种类型，每一种都有其独特的作用。All类型可以完成广播和洪泛，即执行所有的bucket，当每个bucket指定转发到特定端口就完成了广播。但要注意并不会广播到入端口，若要广播到入端口，必须相应增加bucket指定這个动作。Select类型会根据自定义的算法在bucket中选择一个完成操作，比如可以完成负载均衡。Indirect类型的组表中只有一个bucket，可以更高效地完成同一类型的操作，比如多个数据包要转发到同一个下一跳地址，则可以让他们属于同一个组表。再者，当要重新指定动作时，比如原来目的地址是A,但由于某些原因A不可达，需要修改目的地址，就可以在组表中统一操作，而不用用流表项一个一个数据包修改，极大提高效率。Fast failover 类型的组表可以完成失效备援，总是执行第一个有效的bucket，当当前的bucket出错，就会顺序查找下一个可用的bucket，如bucket1中有转发端口A动作，bucket2中有转发端口B动作，当端口A失效时，可以立即切换到下一个bucket，而不用通知控制器。可以看到，这就是组表的魅力所在。

2、关于meter table

3、关于action set、action list、instruction、apply actions之间的理解

action set和每个数据包关联，即一个数据包会有一个关联的action set，action set在流表之间传递，可以利用instruction中的相关类型如写入动作或清空动作对action set进行更改。Action set默认指定了动作的执行顺序，如果不想要按照action set中的默认顺序执行或者想自定义顺序执行一些额外动作可以用action list。注意只有apply-action指令和packet-out message会关联一个action list。Action set总是在匹配最后一个流表后自动执行。

instruction和每一条流表项相关联，当数据包匹配到相应流表项时就会执行流表项中的instruction，instruction包含以下几种动作:

（1）Meter，将数据导向到一个指定的meter table，进行相应的QoS处理。

（2）Apply-actions：这个动作和packet-out message都会包含一个action list。Apply-action用于在流表之间处理一些动作，不会影响action set，也不是直接执行action set中的动作。

（3）Clear-actions, 这个指令并不包含任何的动作, 它的行为是立即清除报文的 action set 中所有的动作

（4）Write-actions actions(s), 这个指令真正的包含动作, 它的行为是将自己包含的动作合并到报文的 action set 中

（5）Write-Metadata metadata / mask, 这个也不包含动作, 用的不多

（6）Goto-Table next-table-id, 这个指令也不包含动作, 它表示把报文交给后续的哪张流表处理. OpenFlow 协议要求交换机必须支持这个 action, 但有一个例外是假设你的交换机本身就只支持一张流表, 那可以不支持这个 action.

4、控制器和交换机之间的消息

支持三种消息类型：controller-to-switch, asynchronous 异步和对称（symmetric）消息。

controller-to-switch 消息是由控制器初始化的，而且没有要求交换机收到消息后必须响应回复。有以下几种消息类型：

Features：控制器查询交换机能力

Configuration：控制器可以设置（set）和查询（query）交换机的配置参数。

Modify-State：Modify-State 消息是由控制器发送给交换机的，以此来管理交换机的状态。其最初的设计用意是：增加、删除和修改流表项和组表项（flow/group entries），以及设置端口的性能。

Read-State：收集交换机的各种信息

Packet-out：这个消息可以使交换机的指定端口发送数据包，可以用来转发来自“packet-in”消息的数据包。Packet-out 消息必须包含一个完整的数据包或者一个“buffer ID”，这个 ID 指向保存在交换机中的数据包。这个消息也必须包含一个动作列表，按动作列表中的先后顺序对数据包进行操作；空动作列表表示删除数据包。

Barrier：Barrier request/reply 消息是控制器用来保证“消息依赖”（message dependencies）已经满足，或者是用来通知控制器某个操作已经完成。

Role-Request：Role-Request 消息是交换机用来设定其 OpenFlow 通道角色的，或者用来查询这个角色。这个命令最有用的场合是交换机连接多个控制器的时候。

Asynchronous-Configuration：Asynchronous-Configuration 消息是控制器用来设置额外的“异步消息过滤器”的，通过此设定，OpenFlow通道可以接收它想要的异步消息。或者用此消息来查询这个以上设定的“过滤器”。这个消息在交换机连接多个控制器的情况下非常有用，并且此消息通常在建立 OpenFlow 通道时执行。

asynchronous 异步消息：异步消息由交换机向控制器发送，用来指示数据包的到来，出错或者交换机状态改变。

Packet-in：通知控制器有消息要到来，如交换机的table miss消息要发送给控制器或者TTL检查等事件都会事先发送Packet-in消息。注意，如果交换机有足够缓存，整个packet-in事件中不需要发送整个数据包而只需发送一些头部片段和buffer ID，控制器在发送packet-out消息对其进行控制（含有一个action list），如果没有足够缓存或者不支持内部缓存，就需要将整个消息发送给控制器。

Flow-Removed：通知控制器有流表项从流表中删除。只有设置了 OFPFF_SEND_FLOW_REM 标记（flag）的“流表项”在删除时才会发送 Flow-Removed 消息。生成这种消息，一来，作为控制器“删除流表项”请求完成情况的响应信息；二来，用作流表项超时，交换机将其删除，向控制器发送的通知。

Port-status：通知控制器交换机的端口状态有变化。交换机在端口配置或端口状态发生改变时，应该向控制器发送 Port-status 消息。产生这个消息的事件有：“端口配置改变”，例如，端口被用户关闭、链路断开。

Error：交换机通过 error 消息通知控制器出现问题（或故障）。

Symmertric 对称消息交换机和控制器任意一方发送。

Hello：当建立连接时，在控制器和交换机之间交换 Hello 消息。

Echo：Echo request 消息可以从交换机发出，也可以从控制器发出，收到此消息后必须以 Echo reply 消息回复。此消息用以验证 controller-switch 连接存在，也可用来测量此连接的延时及带宽。

Experimenter：experimenter 消息为交换机提供一个标准的方式，用以在 OpenFlow 现有消息类型范围外，添加额外的功能。这也是为将来的 OpenFlow 修订设计的筹划区域。

消息处理

重点注意下message Ordering，一般交换机会任意重排消息已达到性能最优，可以通过controller-to-switch中的barrier消息来指定相应的顺序。当发送barrier消息时，之前发送的所有消息必须处理完才会处理接下来的消息。

5、多控制器问题

一个openflow交换机可以与多个控制器相连，主要是解决失效备援和负载均衡。默认情况下，每个控制器处于处于OFPCR_ROLE_EQUAL，可以执行所有操作，如交换机状态查询，流表修改等。可以改变状态为SLAVE或MASTER，但一个交换机只能有一个MASTER，其他的会自动变为SLAVE，MASTER和EQUAL功能类似，但SLAVE只具有查询功能，没有配置交换机功能。

Asynchronous Configuration 消息可以过滤信道中的消息，利用这个特性，不同控制器可以收到不同的通知，一个“主控制器”可以选择性地禁止它不关心的消息，而一个“从控制器”可以选择想要监控的消息。

控制器可以将自己从SLAVE改为MASTER，执行这个改变时，交换机就会把另一个MASTER改为SLAVE，为了检测 master/slave 转换过程中消息的乱序，OFPT_ROLE_REQUEST 消息包含一个64位的序列号字段，generation_id，用来区分主从关系视图。当交换机接收到来自控制器的消息时，会比较其中包含的generation_id，如果比他小，说明这是一个旧的MASTER，把消息丢弃，并回复一个错误类型消息。

注意到，交换机必须忽视角色为 OFPCR_ROLE_EQUAL 的 OFPT_ROLE_REQUEST消息中的 generation_id，因为generation_id 是专门为了明确 master/slave转变的竞争条件。

6、辅助连接

控制器到交换机之间可以有主连接和多个辅助连接，每一个连到控制器的交换机连接，被标识为交换机 Datapath ID 和一个 Auxiliary ID（见A.3.1）。主连接的Auxiliary ID 被设为 0 , 而辅助连接的Auxiliary ID 必须为非 0 ，Datapath ID 与主连接相同。辅助连接必须使用与主连接相同的 source IP address，但是可以根据配置使用不同的端口号。但辅助连接和主连接必须要有相同的目的IP和目的端口号。换一句话讲，相当于交换机连接到控制器的所有连接中，源IP和目的IP都一样，目的端口号要一样，但源端口号可以不一样，实现多对一连接。达到增强交换机性能，提高并行能力。

交换机在启动附加连接之前必须完成主连接的启动，交换机只有在主连接存活时才维持辅助连接。辅助连接的建立与主连接的建立使相同的。当交换机发现主连接断开，它应该立即把所有与控制器连接的辅助连接关掉，以使控制器可以正确处理 Datapath ID 冲突。

7、流表修改消息

8、metadata

说明书中表述为：Metadata may be used to pass information between tables in a switch 。

metadata(可以)用作table之间的标记。传递信息。

9、openflow 的 OXM机制

http://cifer.me/openflow-oxm-tlv.html

早期的 OpenFlow 协议对于匹配项处理的不是太好, 一个是匹配结构体固定, 所有的匹配项都包含在一起, 下流表时即时不需要这个匹配项, 也要一并下发下来, 加大了网络开销; 另外最重要的是这个定义毫无扩展性, 想要增加新的匹配项就等于再更新一版新的 OpenFlow 协议.