OpenState: Programming Platform-independent Stateful OpenFlow Applications Inside the Switch

  • 文章名称：OpenState: Programming Platform-independent Stateful OpenFlow Applications Inside the Switch
  • OpenState：在交换机内部实现编程平台无关的带状态OpenFlow应用程序
  • 发表时间：2018
  • 期刊来源：ACM SIGCOMM Computer Communication Review

ABSTRACT (摘要)

软件定义网络设想由中央控制器管理dumb的廉价交换机。事实上，在交换机上添加某种级别的控制逻辑可能对于降低逻辑集中的中央控制器负载有很大帮助，这些控制逻辑可以在交换机内以线速进行解决。同样的，它可以减少下发到特殊的中间盒设备进行流处理的任务数量。潜在的挑战是，我们是否可以设计一个带状态数据平面可编程概念（相对无状态的OpenFlow match/action table 而言），它仍然需要高性能并且与服务商的偏好相一致。我们认为一个有希望的答案围绕着扩展有限状态机的使用，作为OpenFlow匹配/动作抽象的扩展（超集）。我们具体的将我们提出的概念变为一个实际的基于表的API，而且，或许令人惊讶的是，我们展示了如何（主要）重用已经在OpenFlow设备中实现的核心原语来支持它。

1 INTRODUCTION(介绍)

OpenFlow的出现是为了改变配置不同服务商提供的设备非常困难的情况，OpenFlow的方法是识别与供应商无关的编程抽象，以便配置交换结构的转发行为。通过OpenFlow应用程序接口（API），网络管理员可以远程配置运行状态的转发表，探测流量统计，并且将与本地流表项不匹配的数据包转发到控制器，做进一步的处理以及做出相关的决定；OpenFlow将SDN带入到现实世界。通过OpenFlow 的“match/action”概念，设备编程人员可以通过首部匹配规则广泛的指定一条流，对匹配的数据包关联转发/处理动作，并且访问指定数据包的字节/数据包信息。

1.1 “dumb” switches: choice or compromise?

OpenFlow版本到2014已经发展到了1.4版本，但是和最初的简单概念相比，复杂了很多，为了满足现实世界的需求，OpenFlow协议不断扩展，这可能最终威胁到OpenFlow发明者的原始供应商独立目标。

结果，尽管OpenFlow设备现在有许多功能和原语，但是它仍然显得“dumb”，所有的“smartness”被放在控制器上。在最好的情况下，这会导致额外的信令负载和处理延迟，并要求对逻辑“中央化”控制器进行毛细管分布式实现。在最坏的情况下，先前非常慢的控制平面操作阻止了对网络控制算法的支持，这需要在数据平面转发行为中进行快速，实时的重新配置。

1.2 Contribution

如上所述，OpenFlow的主要的缺点是它没有能力让程序员在设备本身部署状态。仅仅为OpenFlow加上状态是不够的：程序员应该有能力规范状态如何进行处理，并且这个配置应该在设备之外执行，同时没有控制器的参与。一个可行的解决方法必须有以下两个基本特性。

  • 1，必须适合高速实现
  • 2，必须不违背服务商敏感原则，它应该是一个具体的可编程概念，而不是一个技术方法。

我们的工作主要在第二个方面：尽管在第3节关于我们提出的方法有一些提示，它可以被现在OpenFlow硬件高效地支持，我们并不认为它对这方面的问题已经完全解决。 ** 相反，我们主要的贡献在于提出了一可行的个概念，这个概念正式地描述了在设备内部进行期待的带状态流处理，同时不暴露设备内部的设计实现。**

我们的概念依赖于eXtended Finite State Machines（XFSM），最近被认为在不同网络区域、平台无关的无线媒体访问控制编程性上具有高效性。 具体地说，本文将在section 2引入简化的XFSM （我们称之为Mealy Machine）以及相关的可编程接口，这可以解释为OpenFlow匹配/动作抽象的一种自然概括。在section 3，我们将讨论可行性和实现问题，展示XFSM支持可以大量的重用现在的OpenFlow特征。最后，section 4讨论了完全支持XFSMs和可能的益处。

需要扩张OpenFlow数据平面的概念最近才被研究社区意识到。在[15],作者指出现在硬件交换机古板的表结构限制了OpenFlow数据包匹配固定字段以及动作集的处理，并且在现有的固定物理表和动作原语上介绍了一种逻辑表结构RMT(Reconfigurable Match Table)。显然，提出的方案允许不仅考虑了首部向量任意匹配的宽度和深度，同时定义了可以作为输入参数、修改首部字段的动作（action）。在[16]中，这种方法更加激进，与早期的主动网络工作类似，允许数据包携带一个微小的代码，在交换机数据平面中进行精细处理。一个非常有趣的方面是有针对性的ASIC实现的提议，其中可以使用极小的指令集和存储器空间来定义分组处理。OpenFlow扩展似乎为其增加更多的功能和能力，但是对于如何适当地在一个干净的API上适当的容纳它们的关注却非常有限。

最后，XFSMs的使用灵感来源于[8]，在[8]中，XFSMs被用于传送期望的媒体访问权限控制操作到无限接口卡。尽管概念相似，但是背景，技术选择和事件处理没有可比性。

2 BASIC ABSTRACTION

2.1 An illustrate example

OpenFlow数据平面概念，在1.1版本基于单表的match/action规则，并且从1.1版本后是多表。除非远程控制器通过flow-mod消息明确更改，否则规则是静态的，比如，一条流的所有的数据包经历同样的转发行为。

然而，许多应用程序将受益于逐个分组地演进转发行为的能力，即，取决于我们到目前为止已经接收到的数据包序列，比如，依赖于目前已经收到的数据包序列。一个很好的例子就是端口访问，是防火墙开放端口的一种著名的方法。一个主机视图建立一个连接（称之为ssh会话，比如，端口22）传送一些列数据包，发送到预先指定的封闭端口有序列表，比如端口5123,6234,7354和8456。一旦接收到到数据包的精确序列，防火墙将为对应的主机打开22端口。在打开端口之前，收到的数据包都将被丢弃（drop）。

与其他带状态应用一样，这样的操作不能在OpenFlow交换机内进行配置，但是必须在外部控制器上实现。花费的代价是要将大量的信令信息（原则上直到所有封闭端口的数据包）传送给控制器。而且，一个及时的控制器flow-mod 命令需要在正确的访问序列之后打开22端口，防止合理序列之后的ssh数据包发现22端口仍然关闭。另一方面，在控制器上实现这样的应用并未带来利益：它不会受益于网络范围的知识或高级别安全策略[17]，但只使用与特定流量相关的本地状态。

无论如何，让我们先推迟关于在哪里实现这个操作的讨论，并且集中于我们可以如何model这样的期待的行为。按理说，最自然的方式是将每个主机与图1中所示的有限状态机相关联。开始于DEFAULT状态，每个正确的端口访问会导致过渡到一系列三个中间状态，直到到达最后的OPEN状态。期间，任何一个不符合期望的端口访问会导致端口状态回到DEFAULT状态。当再OPEN状态时，数据包将发送到22端口（并且只有在这个端口将被转发），而所有其他的包将被丢弃，但是不会将状态重置为DEFAULT。

2.2 Extended Finite State Machines

仔细查看Figure 1，揭示了每个状态迁移引起的事件（event），详细的包含数据包匹配的给出端口。而且，event match 引发每个状态迁移，引起相关的动作（转发/丢弃）。因此，状态转换非常密切地提醒传统的OpenFlow匹配/操作规则，但是放在一个更通用的框架中，其特征在于以下两个区别方面。

2.2.1 XFSM Abstraction

配置了event的匹配不仅依赖于数据包头信息，并且依赖于状态（state）；用上述的端口访问例子，当处于OPEN 状态时，一个数据包携带了port =22，关联一个转发动作，但是在其他的状态时，关联的是丢弃动作。而且，事件（event）不仅导致action，同时引起状态迁移到下一个状态（包括状态迁移到本身，状态不变的情况）。

所有的这些可以通过简化的eXtended Finite State Machine (XFSM)，即Mealy Machine，建模成一个抽象的形式。正规地，这样简化的抽象模型包含一个四元组（S，I，O，T），另加一个初始的开始状态（default）S0，

  • i)S 是一个有限状态集；
    • ii） I是输入信号（events）的有限集合;
    • iii) O是输出有限集（action）;
    • iv) T是S×I -> S×O ，是一个状态迁移函数，映射<state,event>对 到<state,action>对。
  • 类似于OpenFlow API，通过限制集合O为当前OpenFow支持的动作，以及限制event集合I为OpenFlow 匹配的首部字段和元数据，使其在硬件平台简易地实现。，使概念变成具体的（保留平台的独立性）。有限的状态集S（具体地，状态标签，比如bit 串），以及相关的状态迁移，本质上，带状态应用的“behavior”，导致了程序员的自由。

2.2.2 State Management

OpenFlow中的匹配通常在流表中收集。**到目前为止进行的讨论建议明确区分定义事件的匹配（端口访问示例中的端口匹配）与定义流的匹配，意味着归属于状态的实体（主机IP地址）。 ** 而event匹配对给出的流造成状态迁移，并且被XFSM所配置，流匹配负责识别和管理到来的数据包所属的流的相关状态。不同的表（XFSM table 和State table)，以及三个逻辑步骤自然地出现以处理数据包（见Figure 2）。

    1. State lookup: 使用表示一条流的数据包头字段（可以标识这条流），作为键查询一个状态表（State Table），比如源IP地址；如果为没能对应的流查找到一个状态，我们可以将返回default状态；
    1. XFSM transition: 被检测到的state标签，作为元数据添加到包中，和首部区域一同用于XFSM表的匹配。返回相关的动作以及下一个状态标记。
    1. State update
      这包含使用重写（或者增加）下一个标签到state table中。

Figure 2中的例子展示了端口访问例子是如何通过我们提出的方法进行支持的。包含在XFSM表中的程序（7个条目）实现了端口访问状态机。假设从1.2.3.4来了一个数据包，state lookup（图顶端）允许检测当前的状态，是STAGE-3。通过XFSM表（图中间），我们确定这个状态，伴随着的访问端口号为8456，触发了一个drop动作，并且状态变化为OPEN（图中间）。新的状态为对应的主机表项写回到状态表（图底部）。在XFSM表中，我们假设有序的匹配有限集，最后一行有着最低的优先级。因此，对于与预期的已访问端口不匹配的数据包，所有四个转换到默认状态都会在最后一个条目中合并。所提出的解决方案的一个显着特征是表的长度与流的数量（状态表）和状态数（XFSM表）成比例，但与其产品无关。

2.3 Flow identification

上述抽象仍然遗漏了一个基本的进一步的步骤，它允许对重要的带状态操作的子集建模，其中给定流的状态由在不同流上发生的事件更新。一个重要的例子是MAC学习：数据包通过目的地址进行转发，但是转发的数据库是使用源MAC地址进行更新。相似的，对于双向流的处理可能有同样的需要。比如，政策到一个返回的TCP SYNACK数据包可能会在相反的方向上触发一个状态迁移。另外像FTP协议，控制在21号端口上的改变，可能会用于在20号端口上的数据传输会话的状态设置。

引起这个问题的根源是，到目前为止，我们仍没能够概念地将与状态相关的流的标识与首部区域（在其中找到标识符）实际位置分开。因此，在我们提出的概念中，流的识别是需要查找和更新状态表，我们只需要为程序员提供在状态表的这两次访问中使用最终不同的头字段的能力。因此我们定义为“lookup-scope”和“update-scope” 首部区域序列顺序，这将是用于产生访问状态表和执行查找或更新操作的关键。

随着这样的特征，编程MAC学习操作变成不重要了。我们首先定义与流标识（即MAC地址）关联的状态，当前交换机端口应该转发数据包（如果尚未学习端口则为DEFAULT）。在状态查找时，lookup-scope 被指是为MAC目的地址。在状态更新期间，我们将update-scope 为 MAC源地址。最终，我们将使用Table1的迁移填充XFSM表。由于update-scope，用于State Table 更新使用的<key,value>是<macsrc,next-state>。在这个样例表中，我们有意假设与当前OpenFlow配置的兼容性，并且N^2+N大小的表（N是交换机的端口）依赖于OpenFlow的限制，而不是我们的XFSM概念。实际上，我们注意到[15]中最近引入的可重配置匹配表所允许的参数的使用将产生仅包含两个条目的XFSM表：定义一个加上条目状态：port(i)×event : in port(j) ->action : output(i) × next state : in port(j)。

2.4 Application Programming Interface

作为总结，我们基本的数据平面编程概念以正式地配置带状态操作包括两个表的规范。

  • 一个 XFSM 表包括 i)state提供作为用户定义的标签，ii）event 表达为OpenFlow匹配,iii）一系列OpenFlow actions，以及iv）next-state标签，每一行都是设计的状态迁移。
  • lookup-scope和update-scope分别用于访问和更新状
    态表。

现在仍不清楚，在此阶段，对于产生允许在XFSM表中绑定不同 update-scope 表项的API是否会很方便；换句话说，将每个下一状态条目与其更新范围相关联，然后根据所考虑的特定转换而不同（XFSM表中的一行）。实际上，对于这个额外的灵活性，我们仍未找到一个明确的用例，将以额外的内部硬件复杂性作为代价。

3 IMPLEMENTATION ISSUES

3.1 Feasibility analysis

我们首先定义一个交换机架构应该如何概念地扩展以支持我们提出的带状态操作。我们具体集中注意力在，哪些OpenFlow原语可以被重用（如何重用），以及哪些新的原语需要添加。。

3.11 Architecture and primitives

我们方案的一个关键特性是使用state labels执行匹配并使用多个表。这些特征实际上是可行的：因为OpenFlow1.1 引入了table管道处理和元数据支持。一个数据包进入OpenFLow交换机通过一些列相关联的流表进行处理，关联的流表提供匹配、转发、和数据包修改。元数据用于扩展数据包头，这是为了从一个表携带任意的信息到另外一个表。控制器可以通过发送flow-mod消息安装移除流表项。

我们用无状态阶段（stateless state）表示由单个流表操作的处理。反过来，我们定义
带状态阶段（stateful stage）(Figure 3)为一个逻辑的块，由State Table 和 XFSM Table组成，并且实现我们的概念。一个数据包首先通过键 提取器（extractor）进行处理，产生一个比特字符串代表用于匹配状态表中一行数据的键。键是通过把在lookup-scope定义的首部字段联系起来得到的。匹配到的state label被当做元数据插入到数据包首部。为了防止匹配失败（table-miss），DEFAULT状态将插入到数据包头。如果由lookup-scope配置的首部区域没有找到（比如，当以太网类型不是IP时，提取源IP地址，），那么特殊的状态值NULL将被返回。

XFSM table可以在OpenFLow1.1以上版本进行实现，因为标准的流表的表项是使用相关的首部字段代表event和（元数据）state label进行匹配的。我们仅需要配置执行的动作集，作为OpenFlow指令开发的补充命令，特别地，新的SET_STATE指令将会立即触发一个更新之前的状态表的动作。一个指令的使用保证了状态更新是在阶段的最后执行的，即使配置了动作包，也允许使用补充阶段（包括其他带状态阶段）来管理我们的带状态阶段。

通过键提取器对数据包首部进行处理，再重写状态信息，将被定义为update-scope，获得的键将被用于在state table重写或者添加新的一行。状态更新同样可以通过控制器执行，类似于flow-mod，由于这个原因，我们将它们命名为state-mod 消息。

3.1.2 Configuration

我们假设默认情况下，交换机为流水线处理提供的所有流表都是无状态的（即标准Openflow）。控制器可以发送控制信息给交换机，从而可以支持一个或者更多流表的带状态处理。通过将带状态表（state table）与现在的流表和定义的lookup-scope和update-scope进行关联，配置带状态阶段。显然，lookup-scope和update-scope必须提供一样长度的键（keys），在同类的流集合上，XFSM的定义是一致的。

一旦带状态阶段被配置，控制器可以在流表上运行安装表项，这些表项将会匹配流的当前状态。重点注意的是，XFSM的完整描述，可以把安装在流表的流表项集合，看作是由event,state matching ,state transitions action的组合，进行理解。

3.1.3 Support for multiple XFSMs

运行在不同的scopes的多个XFSM项目可以使用多个带状态阶段的流水线技术进行普通的配置。更有趣的不同的XFSMs必须在相同范围进行配置。比如，在端口访问中，我们希望拥有一个地址集合，表示来源于子网 131.175/16，对此，我们希望有一个不同的访问序列，或者甚至是默认打开22号端口，而不用通过访问过程。这可以通过为State Table添加前缀匹配的能力（比如，匹配IPsrc = 131.175..），并且使用优先级排序（或者最长的匹配）确定用于检索相关状态的匹配，从而轻松实现。

3.2 Software datapath implementation(软件数据通路实现)

更吸引人的硬件实现是一个更长远的目标，我们尝试通过发展原型软件实现获取更长远的见解。我们利用提出的带状态操作扩展、支持了OpenFlow1.3软件交换机。我们的实现是可行的，在[19]，因此我们限制于总结主要的修改（很少，作为我们提案影响较小的进一步证明）。

为了支持发布和撇子和提出的状态管理特点，新的交换机能力 OFPC_TABLE_STATEFUL 位被定义，另外还定义了新表配置位 OFPCT_TABLE_STATEFUL。 扩展了基本的流表数据结构，支持state table 和 键 提取器。通过添加新的OpenFlow指令----OFPIT_SET_STATE ，允许OpenFlow扩展datapath，以用next-state参数更新状态表。已经定义一个名为OFP_STATE_MOD的新状态修改消息以及相关的消息结构，以允许控制器分别的配置状态表项和键（key）提取器（lookup-scope和update-scope）。正如简要预料，实际的XFSM table配置和实现已经不要求对现在代码进行任何修改，因为它只是依赖于标准的OpenFlow match table 结构和flow-mod message（除了已经讨论的对新OFPT_SET_STATE指令的支持）。

4 BEYOND THE BASIC ABSTRATION

虽然在前面的部分中概述了我们的基本思想，但我们试图保持对当前OpenFlow功能的基础，以便有希望让读者相信我们提出的建议不是未来主义，而是可以轻松部署。以下，我们抛弃谨慎，然后尝试概括（没有做任何坚定的主张，而是为了激发讨论的目标）同样的可编程模型如何沿着不同的复杂方向扩展，以提供设备程序员更进一步的网络功能编程能力。

我们认同，我们提出的方法并不能实现所有现在中间盒设备上支持的功能。但是，我们希望其中的一些不太复杂的功能可以转移到交换机以支持更敏感的网络反应。

4.1 Improving state handling

  • 软状态和事件计时器。
    在OpenFlow中为状态表表项添加超时是直截了当的，另外API可以被扩展，以允许程序员为每一个状态变换配置不同的超时（timeout）。管理超时过期也很简单的，，但前提是我们假设所有状态在超时到期时返回到DEFAULT状态。实际上，超时可以通过假设状态查找，检索一个到期状态将会返回DEFAULT状态，相比较，处理时间超时作为隐式的事件，这将触发有意义的（非默认的）变换，可能打开更有趣的场景（支持指数退避操作，根据ACK在时间窗口之前或之后返回等来强制执行不同的TCP转发等），但是按理说，要求在实现上有一个意义重大的飞跃。

  • 使用状态标签作为功能参数

  • MAC学习例子如Table1所述，交换机每个可能的端口需要一个表项。通过允许转发动作接收在与数据包相关联的元数据中提供的参数作为输入（在我们的特殊例子中，state label 作为交换机端口交互），这可能仅用两个表项实现同样的程序：一个用于default state （在转发数据库中无法找到MAC 目的地），另外一个将MAC帧转发到状态标签找到的交换机端口。不同的技术方法通过将头部参数传给actions在[15]中有所讨论。

  • 标签上的简单算术运算
    状态和简单算术操作的组合允许多个又去的扩展。例如，我们可以通过转发IP分段来严格编程状态机来阻止一些IP分段攻击，只要它们按严格顺序接收即可。一个基本的IP分段攻击包含发送第一小的分片（分片 offset=0，更多分片=1），然后发送第二个IP碎片声称是一个大的最后一个小碎片（ 64 KB）数据包。这些可以通过“计算”轻松地检测，从第一个IP分片的length，第二个分片期望的偏移量（offset），用它作为临时的状态标签（或者作为一个数字值与分片状态相关），旨在匹配到这样的一个计算的偏移量字段时，转发数据包。我们强调，虽然显然引人注目并且可能激发广泛的扩展，但这样的“算术计算”可能在高速时变得至关重要，并且需要更仔细地研究它们的可行性。

4.2 Enforcing conditions： “full” XFSM

流数据可以被认为是流相关的记忆寄存器。相似地，设备级别桩体，比如当前输出队列的占用，或者设备级别的数据，比如通过给出的交换机端口进行大量的比特传输，可以解释为值存储在每一个fow寄存器。存在这样的寄存器中的值将被用于下一步的条件，触发相关事件的动作。

相当有趣的是，XFSM的定义在[10]中给出，提供了正式地模型，可以长生Mealy Machines(section 2引入)。这可以清晰地解释作为记录值的条件。实际上，在XFSM表中设置条件的能力对于配置无线MAC协议在[8]中被证明是重要的。

从[10]中得出，XFSM是一个抽象的7元组（S,I,O,T,D,U,F），状态S和输入事件I以及输出动作O与第二节定义的相同。

  • D是n维线性空间，D1....Dn，其中描述了n个寄存器的所有可能配置;
  • F 是支持网络功能fi的集合:D->{TRUE,FALSE}，模拟了验证支持状态变换寄存器配置的条件。
  • U 是一个 update functions Ui 的集合：D->D，在部署的寄存器上允许模拟变化。
  • T:S×I×F->S×U×O是一个变化功能，将当前的state,event,和条件作为输入，并且输出next_state,相关的action，以及相关的寄存器更新。

我们认为在之前定义的条件下，可行的"寄存器"，"支持的功能"，和"更新功能"，这些概念是当前的技术可以做到的，因此在将来必定可以更深入的探索。实际上，条件可以在很多场景下进行优化，比如QoS，负载均衡，监控等。

5 CONCLUSIONS

本文目的在于在封闭平台上，为每个流支持带状态处理方向提出前进的第一步，在我们的提案中，并且完全遵守OpenFlow策略，我们采取了非常务实的方法：我们在一般性上妥协，并且我们“限制”对标准OpenFlow匹配/操作规则的状态处理。这允许我们显然地立即产生部署的可编程概念，依赖于大部分在OpenFllow中提供的核心原语和数据结构。我们的抽象概括了OpenFlow匹配/动作规则的可扩展有限状态机，它们在交换设备内直接执行，从而卸载控制器，或许更有趣的是，需要线速的数据包 - 数据包操作，即不能委托给慢（逻辑）集中控制平面操作。

对比SDPA和OpenState感觉表设计很类似。。。

posted @ 2018-11-12 23:33  冰柠檬的夏天  阅读(732)  评论(2)  编辑  收藏  举报