SDPA: Toward a Stateful Data Plane in Software-Defined Networking

最新推荐文章于 2024-11-13 09:57:02 发布

diwu3940

最新推荐文章于 2024-11-13 09:57:02 发布

阅读量296

点赞数

文章标签：网络运维

原文链接：http://www.cnblogs.com/Pan-xi-yi/p/9901819.html

版权

文章名称：SDPA: Toward a Stateful Data Plane in Software-Defined Networking
发表时间：2017
期刊来源：IEEE/ACM Transactions on Networking

摘要

OpenFlow仅仅提供简单的“match-action”范式，对于SDN数据平面来说，缺少带状态转发功能，限制了OpenFlow支持高级网络应用的能力，同时，严重依赖控制器处理状态信息也导致了控制器和数据平面性能问题。本文为数据平面提出SDPA，设计了FP（协同处理单元），FP通过指令和状态表管理状态信息，扩展了OpenFlow的协议，以支持控制器与FP之间的通信。另外设计了软、硬件SDPA架构交换机，证明我们方法的可行性和实用性。另外在一个SDPA交换机上，开发了由带状态防火墙，域名系统（DNS)反射防御，以及heavy hitter detection 组成的网络功能链。

I 介绍

先介绍了SDN架构带来的可编程能力，说明SDN上层智能和状态集中，下层为网络应用服务，OpenFlow是SDN南向接口的一个代表性技术，仅提供"match-action"匹配范式，数据包的处理是通过在控制器下发的流表中，匹配数据包头，再进行相应的动作处理。

OpenFlow技术的不足

一、

OpenFlow仅集中在L2/L3层网络传输，对带状态处理提供有限的支持，没有控制器参与，不能对流状态进行监控。

二、

严重依赖控制器保留数据包的状态，由于在控制器和交换机之间的相关处理延迟和控制通道瓶颈，会导致数据平面和控制平面的扩展性和性能问题。

三、

OpenFlow头字段不能够灵活扩展以满足不同应用的需求。相关的研究努力有P4，以解决这个问题，但是P4仍然不支持直观的带状态应用编程。

为解决以上问题，提出创新的带状态数据平面SDPA架构，以在SDN数据平面支持直观的编程和支持带状态应用的高性能处理。 SDPA提出"match-state-action"范式，这个范式特点是状态信息可以在数据平面维护，并且不需要控制器的参与。基于SDPA范式，我们提出普通的带状态软件、硬件交换机设计，基于这个平台，带状态防火墙和DNS反射防御可以在这个平台上实现。

所做贡献：
- 一、提出一种新颖的带状态结构（SDPA），以支持SDN数据平面带状态应用的直观可编程和高性能处理。SDPA支持“match-state-action”范式，可以用于实现带状态防火墙和DNS反射防御。。SDPA适用于在数据平面需要处理状态信息的不同网络应用。
- 二、设计并且实现了扩展的OpenFlow协议以支持SDPA。通过这个协议，SDN控制器可以与状态处理模块FP（Forwarding Processor缩写）进行通信，在数据平面的交换机上维护状态信息。
- 三、实现了SDPA软件、硬件交换机原型，并且基于SDPA软、硬交换机原型，开发了一个简单的网络功能链，这个网络功能链由带状态防火墙，DNS反射防御和高度侦测应用组成。
- 四、用额外的实验评估我们的方法，结果显示，在基于SDN的网络中，SDPA可以通过可管理的处理开销，大大的降低带状态应用的转发延迟。

本文整体结构：在II中概述SDPA范式的概念，III中清楚表达SDPA架构设计，IV中提出实现，V中进行评估，VI中总结相关工作，在VII中做一些讨论。VIII中结束本文。

II Motivation And SDPA Paradigm

A Motivation

第一、一些应用需要记录每一个数据包的状态信息进行高级处理。同时，状态信息记录在控制器是不合适的（造成控制器和数据平面的性能问题）。

第二、现在的SDN技术在数据平面仅支持有限的带状态处理。

第三、尽管一些应用可以通过中间盒进行实现，但是中间盒缺乏通用的可编程接口，网络中很多中间盒，也难于管理。综上，有必要为SDN数据平面设计支持带状态处理的系统机制。

B SDPA范式

SDPA范式如下图1所示，它添加了一个state字段，以维护流的状态信息，同时不需要控制器参与，当实现带状态应用时（比如防火墙），进入的数据包根据相关的状态信息进行处理，接着，状态信息根据进来的数据包、内部或外部事件进行更新。

III 设计

通过在数据平面添加智能，可以在SDPA架构数据平面维护状态信息。

一、设计了FP（协同处理单元），可以为现有的OpenFlow架构提供兼容性，扩展了OpenFlow指令，在FP和流表之间引导数据包。FP依据之前引入的应用状态迁移矩阵或状态机实现对数据包更为复杂的处理。
二、如图2所示，在状态机中添加STT(State Transition Table)，用来描述每个带状态应用的状态机。在FP中添加ST（State Table）以保留流的状态信息，还添加了AT(Action Table)记录不同状态下的动作。

因为不同的应用在状态迁移上有差异，每个应用处理自身的表集。控制器初始化数据平面，将下发AT、STT、ST到数据平面，在运行时，流的第一个数据包将发送到控制器，由控制器决定哪个应用处理这条流，然后，流表项由控制器下发，指导流进入FP中。同时，控制器发送对应的带状态表项给FP。。流的状态信息在数据平面维护，控制器可以在流到来之前主动地下发表项。以下将介绍每个模块。

A 转发处理器（FP）

FP依据当前的状态和迁移策略维护流的状态信息和处理数据包。在数据平面添加GOTO_ST（n）指令，用于引导OpenFlow管道中的数据包进入FP中的状态表n。在FP处理数据包后，它将把数据包发送回在OpenFlow管道源流表中。在数据包被要求在交换机内，按照顺序地被多个应用处理时，控制器可以下发几个GOTO_ST指令来引导数据包分别的进入对应的应用。另外，在FP中设计了动作，动作可以灵活的扩展以满足应用的需求。这些动作可以以下几类：控制动作：用于引导流表和FP之间的数据包。比如GOTO_ST。处理动作：用于FP处理流，包括SET_FIELD,OUTPUT,DROP,等等。状态操作动作：用于操作状态表，比如STATE_UPDATE。算法动作：他们用于执行算术操作，逻辑动作：用于执行逻辑动作。

B 状态处理

设计了三类表对状态信息进行维护，三个表分别为ST，STT，AT。因为不同的应用可能需要维护不同的状态信息，每一个应用可能需要一个唯一的表集。

ST(State Table)

状态表用于维护SDN数据平面的状态信息（称ST）。STs可以由控制器动态的初始化。当一个应用需要进行带状态处理，控制器可以发送一个信息给FP初始化它的ST。初始化信息包含ST表的所有字段信息。在数据平面，状态是根据进来的数据包或者内部/外部的事件更新维护的。。状态信息可以上传到控制器，故控制器可保留网络的全局状态信息，另外控制器依据应用需求，决定多久对控制器状态信息进行更新。图2右边是ST的结构，State Table定义的"Match Fields"字段，用来匹配数据包字段。它是灵活、可扩展的，依照OpenFlow匹配字段，ST包括等长的匹配字段掩码域。状态域在状态表中清晰地记录了流的状态信息（没有掩码），状态的实现可以基于TCAM或者SRAM。控制器可以发送状态操作信息主动地添加、移除、修改状态表项。

STT(State Transition Table)

设计SST来支持状态更新策略配置，状态更新策略是关于特别的面向连接的协议。状态迁移表配置了迁移策略，指示状态如何根据协议进行转换。状态前仪表包含三个不同的域。分别为State,Event,Next State（见图2）。STT仅在初始化时，由控制器下发到FP。

状态域包括等长的掩码域（mask），可以为不同的事件，模糊匹配当前状态。mask对于高级带状态应用处理非常重要，比如，在heavy hitter detection中，无论计数器的值是多少，当前计数器的状态应该与阈值进行对比。没有mask的话，将会有无数的表项。
Event域是状态迁移的触发器。比如，每个数据包携带TCP标签，触发TCP状态迁移。我们将事件标准化为Param1+ Comparison_Operator+Param2格式。FP可以从数据包、表、交换机、控制器获得Param1和Param2。这两个参数可以来自同样的源地址，比如来自数据包首部的数据包源IP地址和数据包目的地址。操作符限制为<,>,=,>=或者<=。事件在不同的应用中有差异。我们通过判断等式是否满足来判断事件是否检测到，这可以根据相关的STT表项触发状态状态迁移。比如，TCP数据包的flag如果==FIN，连接的状态将会从ESTABLISH到CLOSING。
Next State域可以通过算术或者逻辑操作直接地分配或计算。我们将Next State域定义为type+parameter。现在，我们支持两种类型的Next State 域。分别为DIRECT_ASSIGN，由控制器直接定义，ADD_ONE：Next State字段是当前State+1。

AT(Action Table)

AT用于记录不同状态下的动作。AT的结构如图2所示。"Match Field" 和"State" 域与ST中的域相同。"Action"域描述了对应的动作。我们将动作功能分为以上讨论的几类。一个动作被定义为ActionType+Parameter形式。Actions可以灵活的扩展，只要我们为这些动作分配执行的方法和必要的参数。

C SDPA对带状态应用的支持

很多网络应用可以抽象为对一条流或者流集合定义的状态机。当一个数据包进入FP，FP首先查找在ST中的当前状态，然后使用当前的状态和事件（如果有的话），FP将会查看STT并且查找或者计算新的状态。然后数据包和新的状态将会送到AT进行相应的处理，同时，新的状态将被更新到ST中，最后，数据包返回给OpenFlow管道进行下一步处理。

文中列举一些带状态应用，如表1所示，同时对带状态应用分为两类概念：有限状态机和无限状态机。

1）有限状态机

一些带状态应用监控状态可以抽象为有限状态机，比如TCP连接状态。考虑带状态防火墙监控流的TCP状态例子。TCP连接包括SYN，SYN_ACK，ESTABLISHED，FIN_WAIT,CLOSED状态。他们根据在TCP数据包首部的TCP 标记（flags）配置的事件进行状态更新。图3展示了ST、STT、AT设计的带状态防火墙。ST和AT中的match field（匹配域）附带着掩码，并且可以指定为通配符。在STT中的Next Field字段可通过控制器直接地明确地配置。当非法的数据包到来，它们可以通过不合法的迁移很轻松地识别并且丢弃。

2）无限状态机

很多网络应用需要对数据包计数，并且对不同计数器的状态进行反应，比如heavy hitter detection，流大小检测，负载均衡，DDoS检测等，至于heavy hitter detection，为了在服务器或者传统SDN交换机子网检测heavy hitters，控制器需要在流表安装计数规则，然后按时地从交换机上查询计数数据。这个方法有两个限制，（1）频繁查询导致控制器开销严重（2）从交换机上获取所有的计数数据消耗控制器和交换机之间的大量带宽。这些限制呼吁一种机制来解决状态改变，同时不需要交换机与控制器频繁进行通信。接下来介绍在SDPA架构下实现heavy hitter detection。

表的定义如图4所示，SDPA使用ST的状态字段保留流计数器。当一个数据包到来时，我们首先抽取出某个字段，以识别这条流（比如源IP用于heavy hittter detection），然后查询在ST中的计数数据（状态字段）。STT负责增加counter的值，并且检查计数值是否大于阈值。。我们在STT表的 state 字段配置一个通配符匹配规则，并且在 event 字段与当前的状态阈值对比。这里，event 的param1是从ST中的状态抽取出来的，param2通过控制器分配。如果计数器比阈值大，流的状态将被更新为OVER_THRESHOLD，否则，计数器加一。AT 依赖流的新的状态配置动作。如果新的状态是OVER_THRESHOLD，那么交换机将发送数据包给控制器，告知检测到heavy hitter。否则，数据包通过。

SDPA APIs

为了支持灵活定义带状态功能，我们在控制器之上定义了北向APIs，另外在控制器之间定义了南向APIs，北向API主要用于操作员编写应用，包括确定应用的处理逻辑和表结构。南向APIss主要用于控制器和FP之间的交流。控制器通过南向结构初始化、修改FP中的STs、STTss和ATs。我们阐述API设计如下：

1）SDPA APIs关键组建

SDPA APIs 包括以下关键组件，（1）Match field(匹配字段)：匹配域的定义描述了每一条流的标识符，比如TCP连接的五元组。匹配字段可 (2)State（状态）: 状态可以定义为枚举类型变量，比如enum state 为{1,2,3，....，n}，交换机不需要知道每个状态的意义。控制器可以通过枚举的状态（state）值构造状态表和状态迁移表。（3）Event:一个event是状态迁移的触发器。比如，TCP数据包携带一个 flag，进行状态迁移。。（3）Action：我们配置动作处理不同状态下的数据包。Action可以灵活的扩张，只要我们在控制器和数据平面分配他们执行方法和参数。SDPA支持的动作如III-A所示。

2）南向API

控制器和FP通过南向APIs进行交互，是传统OpenFLow 协议的一个扩展。南向APIs主要用于操作数据平面的状态信息，比如从控制器给FP初始化、修改表项，控制器对于FP有完全的控制。

用以上四个组件，我们定义了两种消息类型，控制器->FP的消息和SDPA南向接口异步消息。控制器到FP的消息用于控制器管理或者查看FP的状态。控制器到FP的消息主要包括：

表初始化消息:用于初始化FP中的表。
表项修改消息：用于添加、修改、删除状态表（State table）和动作表的表项。
交换机配置消息:他们用于控制器配置数据平面属性，比如状态报告间隔。需要注意的是，控制器到FP的消息可能要也可能不要FP做出回应。

异步消息主要用于FP初始化并且将状态改变更新到控制器。控制器不询问时，这消息也会发送到控制器，FP发送异步消息给控制器，表示状态改变或者其他的时间。包括STATE_ENTRY_REMOVE、STATE_ENTRY_MODIFY。当一个状态表项因为超时而移除时，STATE_ENTRY_REMOVE消息将被触发。状态表的表项改变时，FP将发送STATE_ENTRY_MODIFY消息告诉控制器。

北向接口：北向接口用于为操作员提供带状态应用编程。北向接口可以分为三类：

（1）表格式功能，用户调用这个接口来定义表字段，比如match fields，state,event 和 action。我们在当前的实现上提供固定的字段集合选择。但是，这个字段集合可以通过应用需求进行灵活的扩展。
（2）消息构造功能，用于控制器和交换机建立消息迁移，包括表的初始化和修改以及交换机配置。
（3）消息迁移功能，用于将消息迁移到交换机。

E SDN交换机架构支持SDPA

我们设计了一个SDN交换机架构以支持SDPA，如图5所示。我们添加FP和状态表给SDN交换机架构来维护在数据平面的状态信息。另外，增加了策略模块，用于调整处理策略。这个模块包括STT和AT以及以上讨论的关于状态相关的配置。新的架构包-含以下功能模块：

网络接口：直接与物理层相连，主要的功能包括接收/发送数据包和数据包处理。工作在物理层和链路层。
转发引擎（Forwarding Engine）：用于决定数据包的转发路径。为转发操作解析收到的数据包头和查找流表以获取目的端口。
转发处理器： FP与控制器交互，并且负责维护和管理数据平面的状态信息。
Flow Table（流表）：扮演连接整个系统的角色。它可以根据控制器下发的信息进行更新并且返回相关的转发指令给转发引擎。
State Table ：用于数据平面程序处理时，维护数据平面处理状态信息。
Policy Module: 它用于存储来自控制器的处理策略，包括整个STT，AT，状态报告间隔策略的配置。

F SDPA架构中的控制器增强

在SDPA架构中，除了控制器传统的集中控制功能以外，我们用更高的性能改进了控制器以支持带状态应用。我们在交换机内部设计了FP，使用SDPA南向接口进行控制器和交换机之间的的通信。控制器能够初始化交换机内的应用，在运行时，控制器可以主动地增加、修改、删除FP中的表项。此外，控制器能够配置交换机属性，包括状态报告间隔等等。从应用的角度来看，控制器提供北向接口，为应用提供修改ST，STT和AT，以实现带状态逻辑处理。

控制器可以按时地接收来自数据平面的状态报告，并且为状态异步更新本地状态记录。交换机不需要在每次状态（迁移）更新时通知控制器，这样可以节省网络的带宽和减轻控制器负担。存储在控制器上的状态可以用于故障恢复，控制器可以将故障交换机的状态安装到新的交换机上，并且对应的指导流。由于控制器可能不能够处理最新的故障交换机状态，安装在新交换机上的状态可能与老的交换机上的状态不一致。支持交换机故障恢复并且状态一致超出本文讨论范围。

注意，在SDPA架构中，控制器仍然是智能指挥中心。传统的功能比如链路发现，拓扑检测，转发等等仍然运行控制器上。我们在这个架构中添加SDPA协议，并且在数据平面维护状态，为带状态应用提高两者的性能和可扩展性。

IV SDPA交换机实现

A 在软件上实现SDPA架构

B 在硬件上实现SDPA架构

C 网络功能链的定制

D 在硬件交换机上动态部署应用

E 弹性SDPA架构

V 评估

实验对比：

A、SDPA架构下的软件交换机性能vs传统OpenFlow软件交换机性能

B、无状态转发软件交换机性能vs传统OpenFlow软件交换机性能

C、带状态表的弹性测试，这个测试时关于SDPA软件交换机表大小和它对于延迟和吞吐量的影响

D、在SDPA硬件交换机中带状态防火墙vsSDPA软件交换机带状态防火墙

E、SDPA硬件交换机带状态防火墙性能 vs 在传统OpenFlow硬件交换机无状态转发性能

F、SDPA硬件交换机中实现网络功能链性能 vs SDPA软件交换机中实现网络功能链性能

VI 相关工作

VII 讨论

A SDPA流迁移

当一个交换机过载，操作员需要将交换机的一些流迁移到其他的交换机上。对于带状态应用比如带状态防火墙，迁移流意味着迁移ST，STT和AT表项。我们可以参考OpenNF [15]并增强SDPA数据平面和控制平面，以实现SDPA交换机之间的无损和保序状态迁移。如上介绍，SDPA硬件交换机的软件层负责与控制器通信。因此，软件和硬件交换机在反应状态迁移时会是一致的。