SDN学习三

目录

一、openflow协议的演进

1.1基于多级流表的协议架构演进

1.2 协议的细节变化

二、openflow协议面临的问题

2.1协议消息类型尚不完善

2.2控制平面的安全性与扩展性问题

2.3 数据平面的设备性能问题

---

一、openflow协议的演进

openflow v1.3版本是ONF组织宣称稳定的版本。

1.1基于多级流表的协议架构演进

openflow协议v1.0的单流表匹配模式下，虽然流表不熟起来比较简单，但是当网络需求变得越来越复杂是，各种各样的策略放在同一张表中显得十分臃肿，这是控制平面的管理变得十分困难，而且随着流表尺寸和数目的增加，对硬件性能的要求也越来越高。

为了解决上述问题，openflow v1.1设计了“流水线+粗表”的协议架构，并在后续版本中得到沿用。

所谓安全通道其实就是证书交换的建立。。。貌似。

多张串联起来的流表就形成了流水线，数据分组在多张流表间跳转以完成匹配。在分析流水线匹配流程之前，先来介绍一下后续版本协议中的流表项结构。作为openflow协议中最为核心的部分，流表项结构的演进意味控制平面控制粒度的细化，后续版本协议中流表项结构如图：

                                     openflow v1.1/1.2中流表项结构

                                                openflow v1.3中流表项结构

openflow v1.0后续版本的协议将分组头域改称为匹配域（match field），每个版本在原有基础上都进一步丰富了匹配域的内容。为了增强协议的扩展性，从openflow v1.3.0开始，用户可以按需自定义匹配域字段，在后面的小节中将对各版本的匹配域进行详尽介绍。随着协议中概念的丰富，计数器的内容也有细微的改动，优先级字段表示表项在所属表中的优先级，匹配发 生冲突时，以优先级高的表现为准。

相比于openflow v1.0中只有简单的动作指令，后续版本中匹配的复杂化就要求定义更加丰富的处理方法，因此提出了指令集的概念。每个流表项指令集中包含一组指令，当匹配上该流表项时将按一定的顺序执行这些指令，不同类型的指令具有不同的功能：他们可以操作数据分组的动作集，如对动作的增删或立即执行等。

这里动作集的概念和v1.0中动作表的概念有所不同，它是针对每个进入流水线的数据分组而言的，会随着流水线的推进而变化，流水线匹配结束后将按一定顺序执行，而某些指令则可以知道数据分组在流水线的匹配，如在流表间跳转或修饰元数据metadata等，元数据也是在openflow v1.1中提出的概念，它并不是数据分组本身包含的某种信息，而是在不同流表间跳转时所携带的附加信息。

有了前面概念的铺垫，接下来介绍数据分组进入流水线后的处理流程。

流水线处理总是从优先级最高的流表table0开始，根据某个流表进行处理时，将数据分组各个字段与各个流表项中的匹配域对照，如果匹配了某个流表项，那么该流表项中的指令集被执行，这些指令可能会修改分组的动作集、更新计数器，或指定数据分组跳转到另一个流表（goto指令）中重复以上处理。

当新的流表中不存在匹配项时会上交给控制器，或者当匹配到的表项不包括goto指令时会立即执行相关的动作集，两种情况都是为流水线匹配过程的结束。注意，goto指令只能知道数据分组跳转到大于当前所在标号的流表，也就是说流水线只能前进不能后退。

接收数据分组入端口，有处理有转发有执行动作集，没转发就出端口。

为了完善流水线，v1.3.0版本中提出了漏表项的概念，附在每张流标后用于处理该表中失配的数据分组，因此漏表项的优先级必须设置为最小值0.

通过流水线匹配数据分组有很多的优点：以方便，通过提取流表项的特征形成流水线，降低了总的流表数目，提高了匹配的效率；另一方面，这种将匹配过程分解成多个步骤的处理方式，使得处理的逻辑变得更加清晰，允许控制平面根据网络算法分步实现对数据平面策略的部署，增强了SDN的可操作性。

由于流水线匹配是按照流的特征决定处理的方法，所以流表项都有相应的指令集。但是有些指令对不同的流都是适用的。录入，不同的流可能会有相同的下一条IP地址，这是如果每个流表项都添加这个动作，则会在一定程度上造成资源的浪费，影响数据平面转发的效率。openflow v1.1设计了组表来解决了这一问题。OF交换机只存在一个组表，它独立于流水线之外，包含多个组表项。每个组表项可以包含很多的动作筒（action bucket）。组表项的结构如图：

其中，组表项标识符为组表项的唯一标志，counter为该表项的计数器，动作桶里面可以包含很多的动作。组类型则规定了动作桶中指令的执行方法，其定义了一下四种类型，OF交换机必须支持类型为ALL 和indirect的组表项，筛选和快速故障恢复两种类型可选。

组表的调用通过必选动作中的group命令来完成。不同数据流在匹配流水线的过程中，可以指定交友某一组表项进行处理，以执行相同的操作，这种高校的机制非常适合于广播、多播。

1.2 协议的细节变化

数据结构的变化请自行参考请读者自行参考相应的元本协议。

1.2.1 openflow v1.1协议新特性

（1）匹配域

在openflow v1.0的12元组基础上增加了元数据、MPLS标签与MPLS业务类型三个元组。同时支持子网掩码，复用在原有12元组中的IP地址字段里，用于更精确的三层策略。

（2）对MPLS合VLAN标签的进一步支持

（3）虚拟端口

用于一些复杂转发逻辑的抽象。

（4）对FLOW -MOD机制的修改

OPENFLOW V1.0中通过flow-mod下发流标后，不会对相应packet-in消息的数据分组进行处理，虽然它们存在于交换机的存储战中，但是这会导致流的首个数据分组直接被丢弃。

openflow v1.1版本完善了这一过程，当flow-mod消息中与响应packet-in消息中的buffer_id字段相同时。。。先pass。

1.2.3 openflow v1.3.0协议新特性

（1）匹配域

openflow v1.3.0的匹配域字段仍然采用TLV格式，在、、、pass

（4）openflow v1.4协议特性

（8）对流表满载情况的处理

流表存储流表项的能力是有限的，在之前的版本中，当流表满载时，就无法新增流表项了。openflow v1.4 通过允许flow-mod消息对流表项的重要级进行设置来解决这种缺陷。出现上述状况时，若响应流表的ofptc_eviction属性被设置，流表中重要级低的表项将被删除。另外，也可以在表现数目超过一定限度时通过table-status消息通知控制器。

（9）其他变化

新增了OF消息绑定，流表同步的机制，同时丰富了错误消息的类型。

二、openflow协议面临的问题

 

2.1协议消息类型尚不完善

SDN是一种革命性的技术，就2014年前而言，完全脱离传统网络环境对于SDN而言是不切实际的。传统路由-交换网络架构下，私有、公有协议并存，设备通过复杂的硬件设计实现了各种各样的网络功能，不同场景的底层实现区别很大。

SDN的核心思想是控制与转发相分离，最终的追求是控制器的智能与转发设备的通用。因此，为了在SDN中实现传统网络的功能，就要求控制器南向接口协议包含完备的消息类型。虽然每个版本都在不断丰富消息类型，但整体来看openflow在这方面仍有很多缺陷。

2.2控制平面的安全性与扩展性问题

SDN是集中式控制思想的产物，因此当网络规模超过一定限度时，单点控制不可避免的会成为SDN中的瓶颈，而且其安全性也存在很大隐患。openflow无法回避。

openflow V1.2中提出了多控制器的概念，希望通过多个控制器对网络进行协同管控，即通过局部集中，全局分布的方式来解决该问题。

然而，控制器间如何进行故障切换，怎样实现负载均衡，2014年前还在初步设想阶段。还有一种方法是通过集群技术来扩充单点控制的能力。

2.3 数据平面的设备性能问题

传统交换机参照Mac地址转发，路由器参照IP地址转发，通过定制ASIC芯片可以实现高速工作。而openflow将网络协议栈扁平化，协议栈各层次对于转发设备而言不再具有明确的界限，各个网络字段都可以作为流表中的匹配域，通过通配符掩码实现任意字段的组合。相比于传统网络，这种做法无疑大大提高了网络灵活性，但是付出的代价是硬件设备为了适应这种通配的匹配方式，一般来说需要采用TCAM来设计流表，但是TCAM的成本要高出很多，这就限制流表的规模业限制了SDN的规模。

openflow多流表流水线结构同时匹配查表的速度也会受到影响。