[文献阅读]SwitchReduce : Reducing Switch State and Controller Involvement in OpenFlow Networks

 # Abstract

    OpenFlow是一种流行的网络体系结构，其中几种逻辑的控制器（控制平面）与所有转发交换机（数据平面分离）。通过控制器，OpenFlow框架可以实现交换机中的流级别粒度，从而对每个单独的流进行监视和控制。
   这种体系结构的代价是在各种流量工程场景中，对交换机状态大小施加极大的压力，并给控制器造成负担。在沿着流路径的每个交换机上存在着流匹配规则和流计数器，这会导致每个交换机成千上万的条目。
   为了尝试利用较少拥塞的路径，或者由于虚拟机迁移而动态的重新路由流，会导致控制器沿旧路径和新路径对每个交换机进行干预。在缺乏流存储和控制器的安排的情况下，OpenFlow将无法扩展到预期的生产数据中心规模。
在以上的情况下，作者提出了SwithReduce，一种减少OpenFlow网络中交换机状态与控制器参与的系统。SwitchReduce建立在以下observation的基础上：
1）任何交换机的流匹配规则的数量不应该超过它对传入流必须执行的一组唯一处理动作。
2）每个唯一流的流计数器可以仅在网络中的一个交换机上维护。
仿真结果表明SwitchReduce可以将第一跳交换机上的流条目减少多大大约49%，内部交换机上的流条目减少答99.9%，同时将流计数器平均减少75%。

1. INTRODUCTION

   OpenFlow体系结构在物理上将控制平面与数据平面分离。逻辑上集中的控制器（控制平面）通过在转发交换机（数据平面）中安装定制的定制的流规则来独立的控制网络中的每个流。一个流程规则包括一个与给定流程匹配的Match字段，一个说明字段（说明要对该流执行的操作）以及一个用于维护流统计信息的计数器。，因此，OpenFlow通过Counters还可以对来自每个单独流的流量进行监视，从而允许实施各种流量工程方案以及几种控制，也可以微观的实施安全方案和网络策略。
具有这种几种控制和流级别粒度的OpenFlow，为数据中心提供了有吸引力的设计选项。但是有几个重要的问题：

1）交换机的内存需求
   流级别的粒度给交换机状态带来了巨大压力，要存储每一个流过交换机的流的规则，会导致交换机状态随着流的数量线性增加，如TOR交换机有78000个流匹配规则，这就意味着每个TOR交换机存储78000个匹配项和流计数器，这个数字在核心交换机上可能更高，特别是流量计数器。
   如果流经过4个跃点，则网络中有4个交换机为此流提供了计数器，如果网络中有1000000个流，那么网络中就有4000000个计数器，这增加了交换机对RAM的需求，并导致膨胀的交换机状态。

​

   如图1所示，m与n两组流从网络的左侧节点遍历到右侧节点，每组流需要5个跃点，虽然流总数仅为(m+n)，但流级别粒度导致网络中共有5(m+n)个匹配项和5(m+n)个流计数器。
   无法压缩交换机状态使得OpenFlow的数据中心不可行。如超大型计算中心有超过100000个计算节点，这些计算节点包含据具有虚拟主机的云环境，网络中的流数量达到数百万，即使只有两层转发，MAC转发表也需要容纳数十万至数百万个条目，这对于当今的交换机硬件而言不切实际，。
   OpenFlow规则还使用TACM（Ternary Content Addressable Memory），这非常昂贵，因此大多数商用交换机不支持超过5000至6000个基于TACM的OpenFlow规则。
   在OpenFlow网络中，交换机中的条目数甚至比地而成还要多，这是因为它由通过它的流的数量而不是仅由它服务的目标MAC的数量所控制。同样，每个条目的大小大于用第二层转发的相应的60位条目。
   这些事实表明，当今的交换即将无法满足启用OpenFlow大型数据中心的要求。压缩交换机中匹配项和流计数器的数量的任何优化都将直接影响交换机状态大小。

2）控制器瓶颈

   通过在集中控制平面上实施上述流级别粒度会给控制器带来负担，并在控制器上造成处理瓶颈。在动态网络中，可能需要部署各种流量工程策略，控制器变得非常繁重，其任务是更新属于每个重新路由的旧路径和新路径的每个交换机上的流条目。
   如果流的旧路由有5个跃点，而新路由有4个完全不同的跃点，则控制器必须发送9个OpenFlow的消息（mod/add/del）消息。这显然限制了控制器在具有数百万个并发流的生产数据规模上动态更改路由的能力。
   使控制器参与每个流的设置会导致大量的通道流量。对与网络中的每个新流，必须将至少128字节的打包消息发送给控制器。此外，控制器必须将一条56字节的flow-mod消息发送到新流路径上的每台交换机，该消息由控制器确定。
   对于一个TOR，每秒平均100000个流，网络中的100个TOR，以及每个流平均4跳，这将导致仅来自packet-in的消息的控制信道流量超过10Gbps，和超过4Gbps的来自flow-mod的控制信道流量。

3）较高的首包延迟

   交换机上与流规则不匹配的数据包将重定向到控制器，从而导致第一个数据包的延迟约为几毫秒。造成这种延迟的主要原因是需要从数据平面过渡到控制平面。当前在交换机中填充预路由规则是目前减少延迟的唯一方法，但是，交换机的存储器会成为一个约束。这些问题必须要解决才能在大规模生产数据中心部署OpenFlow。
   于是在文章中，作者提出了SwitchReduce，一种用于减少OpenFlow网络中的交换机状态和控制器参与的系统。SwitchReduce利用OpenFlow提供的中央可见性来促进交换机之间的协作，这样可以使工作分开，进而减少了交换机大小以及控制器的参与。交换机之间的这种协作还可以在网络内部的交换机中预先填充流规则，这有助于减少运行时控制通道的流量，控制器的参与以及端到端的延迟。

SwitchReduce依赖于两个重要的observation：
1）任何交换机上匹配项的数量不应该超过它对传入流必须执行的一组唯一处理动作。
2）每个唯一流的计数器仅可以在网络中的一个交换机上维护。

本篇论文的贡献：

1）介绍SwitchReduce的详细设计，并描述其作为NOX控制器应用程序的实现。
2）我们基于两种不同拓扑的真实数据中心流量显示仿真结果，这些结果表明可以通过SwitchReduce获得节省。
3）我们提供了一个案例研究，重点介绍了SwitchReduce通过主动安装OpenFlow规则来减少流设置延迟的功效，并减轻了在动态重新路由流时控制器的负担。

第二部分：SwitchReduce系统设计
第三部分：我们使用一个NOX OpenFlow控制器的应用程序实现SwitchReduce
第四部分：描述仿真结果。
第五部分：SwitchReduce在实际数据中心中的适用性。
第六部分：相关研究。
第七部分：总结。

2. System Design

SwitchReduce的设计基于以下三个基础规则：

1）使用通配符定义动作流。
2）RouteHeader：基于第一跳的路由，以促进以上的通配符
3）分工：集中维护所有交换机的流量统计信息。

2.1 Wildcard Identical Action Flows

   OpenFlow规则背后的基本思想是能够对每个流应用自定义操作，因此，流规则的数量应以动作空间的基数为界。这是第一个基础规则的前提。
   为了便于说明，本节中的讨论仅限于转发规则，就如第五节讨论的一样，此处描述原理可以扩展到更多样化的流规则。对于转发流规则，“操作”字段基本上是流到outport的映射。
   我们观察到有数千条流流经交换机，大多数商用交换机上的端口数少于128。实际上大多数ToR交换机通常只有不到64个端口，而且核心交换机的端口更少。实际上，虽然有数千个流经过交换机，但只有少数几个端口可以使用 ，既只有少数动作是所有流必须共享的。如果我们为交换机中每个唯一的流安装一个条目，那么最终将得到数千个完全匹配的SRAM条目。在容纳数十万个服务器的数据中心，每个服务器运行多个VM，这实际上需要数百万个完全匹配的SRAM条目。
现有硬件是无法实现的，另一方面，如果我们为每个唯一的动作安装一个条目，那么最终只有少量的通配符TCAM条目。
第一条基础规则：
可以并且应该将交换机中所有具有相同操作相关联的流压缩为一个通配符流（第一跳交换机上的流除外）
   专门根据规则进行解释时，以上语句变为：交换机中所有具有相同输出端口的流（第一跳交换机上的流除外）可以并应该压缩为一个通配符流规则。
   第一跳交换机将是启用了OpenFlow的虚拟交换机，例如openvswitch，该vswitch在虚拟机监控程序内运行，在没有虚拟机交换的情况下，ToR将用作第一跳。
   在不是第一跳的交换机上，所有具有相同操作的流都被压缩到一个通配符流条目中。
在第一跳中，源自直接连接的VM的流不会被通配，而其他所有的流都将被通配。请注意，充当某些流的第一跳的交换机也充当某些流的最后一跳。将此交换机用作第一跳的流将不会被通配，用作最后一条的会通配。
第一跳上的流不会被通配的原因：
   每个第一跳的数据流，都需要一个完全匹配的条目和唯一的表示，以执行上述通配符并保持水平控制和统计数据。

2.2 RouteHeaders : First-hop based routing

   要构造通配符规则，必须具有一些通用性（就OpenFlow头字段而言），这些通用性对于流而言是详尽的。然后可以在此公共字段上创建通配符。但是，很有可能在共享相同出口的交换机的流之间可能不存在这种共同性，因此需要进行通配。
当被通配的流之间没有固有的共性时，如何创建通配符。
   本节中作者将会给出这个问题的答案。
   为了实现通配符，我们利用了OpenFlow的以下基本属性：
1）集中的可见性使得控制器了解从源到目标的整个路径。
2）集中式路由控制器可以完全自由的选择任何路由技术。
   控制器利用这些属性来促进交换机之间的协作，以便每个交换机在转发数据包的时候将要使用的出口通知下一个交换机。

此处将详细的介绍算法将数据包的路径分为3个区域：第一跳，中间跳，最后一跳。

   如图2所示，考虑一个三层拓扑，TOR交换机形成了最底层，在虚拟环境中，TOR将被vsswitch替代，聚合层将被ToR替代。

1）第一跳：

   当新流在其第一跳产生时，控制器将在其中安装与动作完全匹配的规则。
   ·将属于该流的数据包转发到该指定端口上（在图2中的示例中，流F1的端口7）
   ·使用“push VLAN ID”，“set VLAN ID”将一定数量的VLAN标头（以下统称为RouteHeader）添加到属于该流的数据包中。
   添加VLAN标头的数量等于从第一跳到目标的数据包路径上剩余的跳数，图2中，F1的RoutHeader是四元数组[6,2,4,3],它对应于4个新添加的VLAN报头，TOR1之后每一跳对应一个。RouteHeader基本上是适当数量的12为VLAN头的连接，每个头唯一的标识在数据包路径上的每个后续跃点上必须执行的操作。
   由于在本节中专门考虑转发规则，因此RouteHeader中的每个VLAN ID值与相应跃点上唯一标识的数据包的出口。为简单起见，我们选择VLAN ID的值与相应跃点上的输出端口的值相同。
   因此，如果某个数据包在交换机上的输出端口是X，则此跃点上的数据包RouteHeader中VLAN ID也将具有值X。实际上，不一定是这种情况，VLAN ID将包含唯一的操作ID，12位最多可以容纳4096个唯一动作。
   顾名思义，RouteHeader承载流将根据中央控制器做出的路由决策进行整个路由。最外面的VLAN ID（最右边）包含第二条所执行的操作ID，下一个VLAN ID包含下一条的操作ID，以此类推。
   如图所示，由于本节中仅考虑转发动作，因此我们将输出本身用动作ID。RouteHeader的最外层VLAN ID（途中F1最右边的值“3”）包含第二跳的出口，下一个VLAN ID“4”包含第三跳的出口（交换机C上的端口4），以此类推。

2）中间跃点

   当控制器在第一个跃点为流安装精确的匹配规则时，它也为中间跃点中为其安装通配符规则。在此通配符规则的match字段中，将除了VLAN ID所有字段设置为“无关”，而将VLAN ID设置为流的操作ID（输出）。相应的操作字段仅包含流的出口。
   此通配符规则既可以安装在第一跳规则同时安装，也可以主动安装。
   由于Switchreduce 中只有很少的通配符规则时事先已知的，因此确实有可能并且建议使用这些规则预先填充内部交换机（“内部交换机指网络中的核心层中的交换机，即除边缘交换机之外的所有交换机”），在虚拟环境中，SwitchReduce可以使用OpenFlow规则制动预填充OpenFlow规则的使用方法（这是目前减少任何OpenFlow网络中流方法）。OpenFlow文献建议使用预填充规则作为减少延迟的一种方法，但是由于事先不知道规则，因此在实践中很难实现。
   根据OpenFlowv1.1规范，它是数据包最外层的VLAN标头，交换机将使用它们执行基于VLAN的匹配。因此，当数据包到达交换机时，它将自动匹配RouterHeader的最外层VLAN ID对应的通配符条目。

​ 交换机在中间跳中安装的流规则为：

   · 当VLAN标头包含给定值时，将数据包的输出端口设置为指定值。如图中交换机C的流F1的VLANID为3时，将输出端口设置为3。
   · 弹出最外层的VLAN ID。
   上面的第一步基于最外面的VLAN标头选择一个输出，第二步将数据包转发到出口之前，从RouterHeader中删除最外面的VLAN标头。因此将修改数据包的新最外层VLAN标头，使其对应于下一跳的操作ID。因此除了转发数据包外，每个交换机还准备与下一个交换机上的正确通配符规则匹配的数据包，交换机之间的这种协作启用了II-A中概述的通配符机制。所有需要转发到特定出口的数据包都将进入交换机，并为其设置最外面的VLANID，以便它们都与正确的通配符条目匹配。

​

3）最后一跳

   最后一跳还包含给定流的通配符规则。相应的操作是：
   · 当VLAN标头包含给定值时，将数据包的输出端口设置为指定值（例如，对于图2中ToR4的流F1，当VLAN ID为6时将输出端口设置为6。）

   · 弹出最外层的VLAN ID。
   在此特定上下文中，转发是交换机执行的唯一操作，而最后一跳与中间跳相同。 实际上，即使在仅转发的情况下，也可以预先填充这些最后一跳规则。 在第五节中，我们讨论了最后一跳扮演的角色与中间跳不同的情况，并考虑了其含义。
   至此，RouteHeaders以这种方式帮助实现了第II-A节中介绍的通配符思想。 让我们仔细查看图2，以了解如何完成通配符。 检查流F2和F3。 F2和F3在两个单独的源－目标对之间，并且在网络中具有非常不同的路径。 但是，它们的路径在网络中的一个链路上交叉，即将A3连接到ToR4的链路。 因此，A3对F2和F3都执行相同的操作。 SwitchReduce试图在A3中安装通配符规则，以使F2和F3都与该通配符匹配。 为此，它创建一个规则，如果VLAN ID为2，则输出到端口2。现在ToR2将RouteHeader [1,2,3,3]安装在属于流F2的数据包中。 交换机A1弹出最外面的VLAN ID，以将[1,2,3]发送到交换机C。
   然后交换机C再次弹出最外面的VLAN ID，以将[1,2]发送到交换机A3。 因此，当来自流F2的数据包到达A3时，最外面的VLAN ID已经设置为“ 2”，因此发生了与上述通配符规则的匹配。 类似地，ToR3在属于流F3的数据包中安装RouteHeader [5,2]。 由于A3是流F3的第一跳（在ToR3之后），因此最外面的VLAN ID已设置为“ 2”。 因此，再次发生与上述通配符规则的匹配。 以这种方式，F2和F3都在交换机A3处匹配相同的通配符。

2.3 Division of Labor

   利用前两个基础原则，即使没有很多的特定流的条目，我们也可以确保控制器仍可以进行流级路由决策。为确保流级别粒度的sanctity（这是OpenFlow的显著特征）不受干扰，我们必须确保控制器仍能够收集流级别的统计信息。
   这是通过设计自动实现的。 回想一下，在我们的第一个基础原则中，我们选择不对第一跳进行通配流。 这意味着，对于每个流量的第一跳，即网络中首次出现的交换机，都有一个完全匹配规则，一个唯一标识。 控制器可以简单地从这些第一跳（vswitch或ToR）交换机收集流量统计信息。 其余的交换机仅需要收集端口级别统计信息（可用于检测网络中的拥塞），而不必参与流级别统计信息的收集。 对于任何可靠的传输协议（如TCP），端到端吞吐量都是一个常数，因此，无论从何处轮询它们，流统计信息都会产生相同的信息。
   例如，假设图2中从核心交换机C（端口3）到聚合交换机A3的链路拥塞。 控制器只需要查看端口3的端口统计信息（它仍然可以）以检测拥塞。 完成后，它可以查看网络中发送到该端口的所有流。 由于控制器为每个流都安装了RouteHeaders，因此可以访问此信息。 它可以简单地维护使用任何给定交换机上任何给定端口的所有流的列表。
   然后，只需要查看相应的第一跳即可确定每个流贡献了多少流量。 这样，它可以控制行为异常的主机。

3. IMPLEMENTATION

   我们已经将SwitchReduce实现为NOX [13]控制器应用程序。 我们在Mininet [15]测试平台中使用OpenFlow 1.1用户交换机实现[14]。 Mininet是一个平台，可使用网络命名空间中的Linux进程在单个PC上创建基于OpenFlow的软件定义网络。
   SwitchReduce NOX应用程序是SwitchReduce的完整的端到端实现。 对于任何网络，应用程序首先要学习其整个拓扑，其中包括网络中所有交换机的位置及其互连，以及主机到ToR交换机的映射。 主机到ToR的映射是通过跟踪每个ToR交换机在控制器上的第一个OFPT PACKET IN事件获得的，在Mininet的情况下，该事件恰好是ARP数据包。 此事件还会触发我们控制器内的主动路由计算算法，该算法会预先计算每对可能的主机对之间的最短可用路由。 一旦实际流量开始，这样做是为了最大程度地减少控制器处理时间。
   在完成主动路由计算算法后，控制器还将使用所有可能的通配符规则预填充网络中的所有内部交换机以及最后一跳。因此，在网络中的流量开始之前，除第一跳交换机外的所有交换机均已安装通配符规则。 这些通配符规则将VLAN ID以外的所有位都设置为“ x”。 VLAN ID设置为输出端口号之一。 因此，通配符规则的数量等于每个交换机上的输出端口的数量。 控制器为这些规则安装的相应操作是：OFPAT POP VLAN（在匹配后弹出最外面的标头）和OFPAT OUTPUT（将流转发到其指定的出口）。 在目标ToR处，删除最后添加的VLAN标头，并将流传递到其目标。
   当一个新的流到达第一跳交换机时，它将一个OFPT PACKET IN发送到控制器。 控制器只需为该流查找预先计算的路由，然后在ToR中安装一个完全匹配规则，并使用相应的操作OFPAT PUSH VLAN和OFPAT SET VLAN VID将所需数量的VLAN标头推送并设置到该流上。 它还安装了OFPAT OUTPUT操作，该操作将数据包从指定端口转发出去。
   我们使用ping来验证算法的功能，并使用“ Wireshark”来跟踪RouteHeader，因为数据包是通过网络传送的（请参见图3中的ping数据包的Wireshark快照，因为它是通过交换机S1从主机H1路由到H2的） ，S2，S3，S4和S5-RouteHeader为[1,3,3,3]）。

4. SIMULATION RESULTS

   当前，所有硬件交换机均不支持OpenFlow v1.1 +。 因此，目前无法在硬件测试平台上对SwitchReduce进行全面评估。 取而代之的是，我们使用模拟来评估SwitchReduce，以量化交换机状态的saving。
   我们开发了一个仿真器，用于仿真数据中心网络。 模拟器使用服务器的数量，每个机架的服务器，交换机及其连接以及拓扑的类型作为输入来创建网络拓扑。 然后，模拟器将用户指定数量的VM随机映射到服务器上。 然后，它获取一个流量矩阵，并将网络中的所有流存储为（源VM，目标VM）对。 为了路由每个流，它使用Djikstra的最短路径算法。 最后，它轮询交换机以检查通过每个交换机的流的数量，并根据输出将它们分组。 该分析揭示了流规则操作中的重叠，并量化了SwitchReduce完成的压缩。 为了清楚地展示交换机状态问题和SwitchReduce所获得的收益的微观视图，我们首先介绍一个适度的树形拓扑结构的结果，该拓扑结构由均匀分布在40个机架上的400台服务器组成。 对于这些结果，我们使用真实的密集流量矩阵。
   随后，我们给出了一个大型拓扑的结果，该拓扑包含在288个机架上均匀分布的11520个服务器。我们在这里针对树形拓扑和fat-tree拓扑评估SwitchReduce的性能。另外，这里我们使用从Benson等人收集的真实数据中心流量特征得出的流量矩阵。
   在每个仿真中，我们创建一个三层网络拓扑，其中包括ToR层，聚合层和核心层。 然后，ToR层包括第一跳。 我们不考虑将虚拟环境用于这些仿真，以便即使在没有vswitch的情况下也能证明SwitchReduce的有效性。 因此，此处给出的ToR交换机的结果被低估了。在真实的数据中心网络中，ToR交换机的收益也将与我们仿真中的聚合和核心交换机的收益一样高。

4.1 400 server topology

   在此拓扑中，有40个ToR交换机，9个聚合交换机和1个核心交换机。 每个ToR连接到两个聚合交换机，而核心交换机连接到所有聚合交换机。 在实验运行中，我们将不同数量的VM打包到服务器上。 我们使用早期工作[16]中的真实且高度密集的流量矩阵来驱动模拟器。
   图4到图7中的结果是使用实数1000x1000密集流量矩阵输入1000个VM的结果。 在图4-图7中，X轴表示开关号。 核心交换机为1，聚合交换机为2至10（在图4和6中），而ToR交换机为11至50（在图4中）和1至40（在图5和7中）。 对于使用的流量矩阵，网络中的流总数为193,478。





   图4和图5捕获了流规则操作中的重叠。 图4捕获了第一跳和中间跳。 图5捕获了最后一跳。 图4和图5都是堆叠的条形图，分别显示了通过交换机的流的数量和对这些流采取的唯一操作的数量。 每条不同颜色的数量是唯一操作的数量，每种颜色的高度是采取该操作的流程的数量。
   对应于图4上编号11-50的ToR交换机的流没有通配符。 这是因为这些流在这些相应的ToR处具有第一跳，因此它们的唯一标识将在网络中的这一点被保留。 通配符将保留图4上所有剩余的流以及图5上的流。 图6和图7分别显示了SwitchReduce在Agg / Core和ToR交换机上实现的压缩。Agg / Core交换机的平均压缩率超过99％，而ToR交换机的平均压缩率则为49％。
   图8显示了流计数器和匹配域条目在整个网络（使用和不使用SwitchReduce）中保持的增长率与VM数量的关系。 流计数器和ToR匹配字段都随着VM数量的增加而几何增加。 但是，在没有SwitchReduce的情况下，增加速率较高，从而导致线路发散。 在没有SwitchReduce的情况下，Agg / Core匹配项的几何形状也会增加，但在使用SwitchReduce时，其保持不变。

4.2 11520 server topology

   我们首先在树形拓扑上运行SwitchReduce。该拓扑具有288个ToR交换机，24个聚合交换机和一个核心交换机。每个ToR连接到两台聚合交换机，而核心交换机连接到所有聚合交换机。我们在每台服务器上打包10个VM。
   接下来，我们在fat-tree拓扑上运行SwitchReduce。机架排成12行，每行包括24个机架。 有288个ToR交换机，12个聚合交换机和12个核心交换机。 每个ToR连接到单个聚合交换机，每个聚合交换机连接到所有核心交换机。 我们在每台服务器上打包10个VM。
   在每种情况下，我们都是根据Benson等人发布的实际数据中心流量特征得出流量矩阵的。根据他们从运行map-reduce样式任务的生产数据中心和大学数据中心收集的数据表明，任何主机与其通信的同机架主机的中位数为2，机架外主机的中位数为4。因此，我们通过为每个主机随机选择2个相同机架的通信主机和4个机架外通信主机来创建我们使用的流量矩阵。假定通信是双向的。

   这些实验的结果显示在图9中，该图描述了通过SwitchReduce在树形结构和fat-tree拓扑结构中获得的减少百分比。 两种拓扑的结果大部分重叠，但有一些细微差别。 两种拓扑中的内部交换机之间是平衡的，而它们都只通过树拓扑中的1台核心交换机。 每个拓扑中ToR的减少百分比在40%。 这比我们的400个服务器拓扑结构减少了约8％。 造成这种差异的原因是，尽管在400个服务器拓扑中只有10个服务器/机架，但在11520服务器拓扑中却有40个服务器/机架。 因此，每个交换机有40个向下使用的端口在使用中，而以前的情况只有10个。 这导致相对较大的动作空间。

5. CASE STUDY - TRAFFIC ENGINEERING

   在本案例研究中，我们考虑了数据中心内的一些典型流量特性。 据Kandula等[17]和Benson等[6]，大多数数据中心流（80％）的持续时间少于10秒，并且通常每毫秒到达100个新流。 他们发现，很少有长时间运行的流（少于0.1％的持续时间超过200s）占总量的不到20%，而持续时间不超过25s的流超过总量的一半。 Benson等在[18]中证实上述统计数据对流量工程的意义在于数据中心网络1）必须扩展已处理大量的流 2）必须在没有 提前假设规模的前提下适应持续时间长或短的流。
   我们已经详细讨论了交换机状态随着网络中流量的激增。 如上所述，以下事实进一步加剧了这个问题：大多数流量是短暂的，到达时间隔很短，随后进入休眠期。这意味着在任何时间，这意味着，在任何时候，交换机都有流条目属于最近过期的流（因为它们还没有超时），同时它也在尝试容纳新的流。这需要控制器干预以删除旧的流条目，这个操作会导致过多的控制器参与并在控制器线程上产生处理瓶颈，以及将在控制器连接到交换机的控制通道中造成带宽瓶颈。或者，它要求交换机仅仅等待（如果它们恰好用完了存储空间）现有流条目超时，然后才能添加新的流条目，或仅仅是由较慢的查找（如软件表）进行存储新流量。
   如第二节所述，按设计，SwitchReduce可自动解决此问题。 任何交换机中的流规则的数量取决于对通过它的流所采取的唯一操作的数量，并且不随流的数量线性增长。 从流工程的角度来看，控制器的主要职责之一是为新流找到最佳路由，因此，交换机对流采取的主要操作是转发，而启用了SwitchReduce的控制器则无需考虑交换机的状态 同时做出路由决定。 这是因为使用SwitchReduce时，通过交换机推送新的流不一定需要添加新的流规则。即使使用被动流安装而不是主动流安装，一旦网络到达“合理繁忙”状态，在此状态中，一些流量会在所有方向上流动，因此流量将输出到所有交换机的所有端口上，交换机中已经安装了可能的通配符规则。因此，通过网络路由新的流不太可能在需要出入口交换机之外的任何其他交换机上安装新流。
   实际上，就像我们在2.2中提到的那样，SwitchReduce是一种非常实用的方法，可以在网络的内部交换机（或第一跳交换机或入口交换机是vswitch的情况下，在网络的所有物理交换机）中主动安装规则。这可以与控制器的拓扑学习模块结合使用，（就像我们在第三部分的实现中所做的一样），当实际流量到达网络时，控制器仅需要找出每个流的路由，并使用适当的RouteHeader在入口交换机处安装规则。本质上，SwitchReduce使控制器完全自由的来选择最佳路径，而不必担心增加沿该路径交换机所服务的流量。同样重要的是，它将流量安装控制器的参与仅限于入口开关。这意味着内部交换机中不存在与流量安装相关的控制通道流量，从而防止了控制通道带宽以及控制器处理线程的瓶颈。
   对于持续时间长的流量（约占总流量的20%），SwitchReduce也不会以任何方式影响性能。实际上，它使控制器可以自由的选择多路径路由以加速此流程，而不必担心在每个路径上增加交换状态。
   最后，也是最重要的是，从流量工程的角度来看，控制器可能希望重新路由某些流以不断平衡网络负载。 它可能需要定期检查网络状态并动态更改流所采用的路径[2]。 然而，这在当前架构中是不切实际的，因为它需要过多的控制器参与。控制器不仅需要找出新的路由，还需要删除原始路径的多个交换机上的流，并在新路径的多个交换机上安装流。 不过，借助SwitchReduce，控制器甚至无需接触入口交换机以外的任何其他交换机，即可动态的重新路由流，它只需要根据新路由重新编写RouterHeader，中间交换机将自动转发此流到新路径。因此，控制器仅需要修改一个交换机上的流量规则，而无需再任何内部交换机上安装或删除任何流量。

   如图所示，考虑从边缘交换机1到边缘交换机12的流，最初，控制器为此流选择路径1-9-10-11-12，但是，由于某些原因，它稍后决定重新路由通过1-9-8-7-4-11-12.在没有SwitchReduce的情况下，控制器必须首先删除已经在交换机10中安装的规则，并修改在交换机9中安装的规则，此外，它必须在8，7，4中安装新规则，因此，需要执行5个控制器干预。同样，如果控制器决定通过1-2-3-4-11-12重新路由此流，则它必须删除交换机9，8，7中的规则，修改交换机1中的规则，并且在交换机2，3中安装新的规则，着需要6个控制器来干预。但是，如果使用SwitchReduce，则控制器只需要对流在入口交换机处修改一次规则即可。

6.RELATED WORK

   关于OpenFlow中的集中式流级别控制的想法，已被记录在案。Mogul等人指出，由于OpenFlow规则是按流而不是按目的地的，因此每个直接连接的主机比传统的以太网查找需要更多数量级的规则。Greenberg等报告说，流向主机的流量比例为10：1。
仅从路由角度来看，有两项工作在概念上与SwitchReduce相似。 这些是多协议标签交换（MPLS）和SourceFlow 。
   MPLS提供了一种将IP地址映射到简单的固定长度标签的方法，并创建了可以进行高速交换的标签交换路径。 需要使用特殊的标签分发协议（LDP）在启用MPLS的交换机之间交换标签，以传达需要使用的标签。 数据包根据MPLS边缘路由器推送到它们的标签堆栈进行转发。 另一方面，SwitchReduce利用OpenFlow提供的集中式可见性和控制功能将RouteHeader嵌入到数据包中，并且无需任何特殊的分发算法。 这使得动态更改RouteHeaders的含义而不中断流量成为可能。
   Chiba在他们的工作中注意到，OpenFlow操作空间比流空间小得多，因此建议不要在交换机中安装按流规则。SwitchReduce也依赖于此观察。 但是，他们的方法仅在核心交换机上减少了流条目的数量，在边缘交换机上没有。 另外，它们也没有解决重复流量计数器的问题。 此外，尽管他们声称自己的技术可用于现有交换机，但交换机需要执行增加的功能，即增加索引计数器并从操作列表访问适当的操作。 最后，作为标头携带的操作列表可能会无限期增长，从而导致潜在的巨大开销。
   我们提供了一个现成的OpenFlow解决方案和一种算法，用于减少整个数据中心网络上的匹配规则和流计数器，而无需对商品硬件进行任何修改。 我们还提供了一种在网络的核心交换机中预填充规则的可行方法，以减少控制器的参与，控制信道流量和端到端延迟。 我们还在模拟器上提供了广泛的实验结果，以测量开关状态的降低。

7.CONCLUSION

   OpenFlow中的流级别粒度的代价是对交换机状态大小和控制器的参与施加了很大的压力。 在本文中，我们介绍了SwitchReduce-一种用于减少OpenFlow网络中的交换机状态和控制器参与的系统。 SwitchReduce利用OpenFlow的集中可见性来促进交换机之间的协作。 它要求流规则的数量以操作空间的基数为界。 此外，可以在网络中仅一个交换机处维护用于每个流的流计数器。 我们将SwitchReduce部署为带有OpenFlow交换机软件的NOX控制器应用程序的实现验证了其可实现性。 我们对具有真实流量跟踪的模拟器的评估表明，可以通过SwitchReduce获得的交换机状态大小的潜在减少。 我们目前正在使用实际硬件在较大的数据中心拓扑上评估SwitchReduce。 我们还致力于处理故障和拓扑更改。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！