OpenFlow性能测试白皮书

摘要:测试一个交换机是否符合ONF要求的规格已经有一个成熟的标准和共识.但是ONF会给符合标准的交换机贴上一个ONF印章。

然而，openflow性能测试仍然处于初级阶段。然而，存在少部分开源工具用来测试openflow性能，这些特性也开始出现在商业测试产品中，这里没有比较openflow产品性能的标准。但是网络建设商们不仅需要知道建设用的器材是否符合ONF功能标准，而且需要知道产品性能是否能达到要求。本文解释了openflow性能测试的重要性并且描述了公司可以自己用来测试openflow性能的方法。

为什么需要性能测试

本文的一些参量

Of解决方案中有一个或多个控制器和交换机，终端用户只关心完整的系统功能。但是建设和整合者需要对每个组件进行单独的评估，以选择出更好的组件。

本文只是针对以太网交换机。文中描述的例子主要是针对硬件交换机。在性能测试方面，它比软件交换机更加综合和有趣。然而软件交换机运行在标准的服务器上，硬件交换机则运用ASICs，它可以增大吞吐量。当然，描述的方法同样适用于软件交换机。

针对of1.3.0

性能测试的目标和挑战

Of交换机不像传统的交换机主要看重包转发能力的测试。它考虑例如交换机可以多快的处理flow-mod（控制器发给交换机的消息，作用是从交换机转发表中增加、删除、修改流表规则）消息和通过of管道怎么处理正交的包。一旦of规则安装到硬件转发表中。包就按照线速率进行转发。这可以用传统的测试方法进行测试。在of管道数据平面中的数据包存在大量流表项，包要进行大量的匹配，实行大量的动作，例如包修改和转发到目的端口。

根据不同解决方案，of交换机性能要求差异也很大。。。。。

有必要对控制器控制交换机增减流表规则性能进行测试

表容量测试

），可以用TCAM

有不同TCAM大小，TCAM的数量也根据商家优化数量和流规则而变化很大

Full 12-tuple match（of规则中，匹配所有12个头，，有些设备商提供掩盖表能力的优化，比如只匹配第二层的头到第二层的内存中而不是利用TCAMs）

广泛地说，表能力测试需要确认流已经安装了（flow got installed）确定何时表满了，指出满的表中有多少流。，对每一个待测的表重复这个过程。

还要考虑如下：

测试不同表容量

确认不同表规模

确认流确实安装了

决策表是否满了

指出如何计算满表的流个数

Flow-Mod Performance

决定了介于何时控制器发送一个flow-mode消息去添加、删除或者改变一个交换机流表中的转发规则和何时交换机能够用到这个转发规则去转发一个数据包的潜在因素。换句话说就是告诉了我们OpenFlow的查询流表多快更新一次。

怎样测算控制器发送flow-mod消息和这个流表规则完成修改之间的时间。

障碍请求/应答是被设计着用来确认交换机是否处理完成一个OpenFlow消息，但不足以用来细粒度的测量这个时间

删除所有表中的所有流。

添加一个最低级别的默认流以便DROP所有数据包，这样就没有东西被转发。

开始发送能够适配所要测试的流的数据包

发送一组flow-mode去添加流。同时给发送flow-mode和从输出端口成功收到数据包盖上时间戳。

计算发送第一个flow-mod消息和收到对应上面所发消息对应的数据包的时间差。除以所增加流的数量去计算完成安装一个flow-mod的平均时间

只要每个表的instrcture包含“goto table”instruction（除了上一个表的id）这个测试就要继续重复。这样可以确保包转发只发生在上一个表已经填充了流之后

在停止核实他们已经被安装之前要发送多少流？尽可能快的增加流，直到收到table-full 反馈。或者可以按照一次性发生10，20，100或者其他速率

所有数量的流都被安装了之后安装流的时间还会增加吗？如果你用的更大的表，会对此造成负面影响。有研究表明，如果TCAM快满了，会使得增加流的时间变长。所以测试不同大小的表

增加、修改。删除一个表的时间是一样的吗？会，三者分别测试

带有通配符的流比full 12-tuple exat匹配的时间更长吗？如果是，要分别测试

packet-in/out性能

控制器打包数据包然后发给交换机来在网络中转发packet-in 相反叫packet-out。因为在应用中非常频繁（拓扑发现，mac-learling，网页认证）所以它的性能很重要。

此性能瓶颈在于交换机本地cpu和ASIC 或者交换机cpu本身的处理能力。交换机性能差别也很多。

Packet-out消息内的规则类型会影响吗？确保测试在po消息中不同的flow-mods

决定发包频率。先估测个大概值，再依次增加至breaking point

包大小会影响吗？很可能会，试着测试RFC-2544中的大小（64，128。。。）

Table-miss flow entry性能

这是openflow1.3.0中新加入的一个步骤。它是用来处理未匹配流的，在之前版本的步骤是机械性的丢弃，他/她给了一个0优先级的通配符，允许一下操作：discard, goto_table, and output to controller（同packet-out）

比较用了table-miss的丢包率和当前默认的所有包丢弃的下降情况。。监视交换机每时间的丢包数

还必须测试交给控制器处理的部分，来测试最大可容忍的交给控制器处理率。

所有流量都用来冲击table-miss来测量最大吞吐量（出口拥堵性能）从所有口进，一个口出。分别记下所有数据通过各个数据通道和仅仅通过控制器的入口速率

匹配和没匹配流的吞吐量性能。用不匹配的需要经过table-miss的流和匹配条目去冲击看到什么点开始影响流的匹配性能，所有出口和控制器口的丢弃的包都要分别检测看看丢包。

流统计测试

统计字段记录着流中匹配的包的数量和字节和上一个次匹配的时间。这个计算时间预示着不活跃的流的移除

记住每个表入口都包含着流包数和字节的计量表。

找出是否高频率地轮询流计量表会影响其他组件的运作

超时测量

每个表都有努力和空闲的超时。这个测试的目的是是否超时都正确

是否正确的移除了要移除的包，或者其中是否有延迟？

紧密度是否被流总数所影响了

精密度是否同时被流超时的数量所影响

管道性能测试

思博伦(Spirent)，安捷伦(Agilent)，福禄克(Fluke)的网络测试产品？

这三个注重的环境都不一样，安捷伦是全面的解决方案，从射频到线缆均有完整的测试方案，也就是说从无线通讯到有线线缆传输及网络认证都是一体的产品，安捷伦也是全球最大的仪器公司，他们的仪器很全面，几乎无论哪一个方面都有解决方案，现在的网络产品并不是单独的，而是多方面的，例如有线网络中一样有AP或者无线路由一样，所以我建议多考虑安捷伦的。

而FLUKE的，大部分都是应用在线缆布线认证和网络应用管理层次，相对安捷伦来说，福禄克要第一个应用档次，但福禄克的应用范围也比较广，在中国具有一定的品牌号召力，楼上的回答比较具有片面性，但也具有一定的使用考虑价值。

思博伦我没有听说过，估计是网络应用级别的，相对来说名气不如上述公司。

综上所述，按照公司影响力和品牌及技术应用层次和技术水平，大致是排列方式：

安捷伦>福禄克>思博伦