一种灵活精确的SDN交换机南向协议性能测试系统

张一凡，李津，虞红芳 ，孙罡

1．中国电子科技集团公司第五十四研究所，河北 石家庄 050000

2．信息系统安全技术国家重点实验室，北京 100101

3．电子科技大学，四川 成都 611731

引 言

软件定义网络（Software Defined Networking, SDN）是一种新型网络架构[1]，它的核心思想是将传统路由器、交换机中的控制平面和转发平面分离，由集中式的控制平面对网络进行管理和维护，通过控制平面提供可编程化的网络接口为多样化的网络管理和服务提供了易用性和可扩展性。

与传统交换机相比，SDN 交换机除了进行数据平面的报文转发外还要通过南向协议接受来自控制器的配置和动态指令。目前，针对传统交换机数据平面的测试已经有了相关的规范[2][3]，测试方法和测试工具都已经比较成熟，而针对南向协议的测试目前还处于起步阶段。所以本文的重点在于突破SDN交换机南向协议的性能测试技术，研究SDN 交换机南向协议性能测试系统。

SDN 南向协议发展迅速，除了最初提出的 OpenFlow[4]协议以外许多传统配置协议如NETCONF[5]、 OVSDB[6]、PCEP[7]等协议也逐渐开始作为传统网络设备的SDN 过渡协议开始使用。目前这些协议均处于发展状态，依托这些协议的技术仍然存在不足之处，对测试系统的南向协议扩展能力提出了挑战。协议测试技术一般分为一致性测试、互通性测试、性能测试和鲁棒性测试四种类型[8]。其中性能测试通过某种特定的方式，按照一定的测试策略对被测实现进行探测，获取其各项性能指标，评价其是否满足用户性能需求，用于确保被测实现可以稳定高效地完成任务。SDN 交换机性能测试内容多而杂，需要频繁配置测试设备、测试环境和工具，生成不同的测试用例和环境，因此需要消耗大量的时间和人力。从国内外对SDN 交换机性能测试的研究来看现有的无论是基于网络测试仪还是基于开源软件的SDN 网元性能测试框架都不能兼顾灵活性和精确性。

1 相关工作

针对SDN 交换机性能测试目前国内外已经有了一些研究和测试活动，但是这些研究和测试大多都是针对OpenFlow 协议开展的，对于其他南向协议，目前大多的文章都是研究其在传统网络中的性能表现。

本古里安大学的Gelberger 等人[9]研究了SDN架构所增加的网络复杂性对网络性能的影响。他们通过分析交换机延迟、吞吐量和抖动三个指标试图探究网络的可编程性与性能影响之间的关系。他们针对吞吐量，使用了一个标准工具iperf 来建立一个TCP/IP 流，具有各种TCP 窗口大小，从5K 字节到10M 字节；针对延迟，使用不同帧大小生成合成帧，并使用额外的时间戳来计算延迟；针对抖动，通过计算相邻报文延时的变化来计算抖动。最后发现SDN 网络的复杂性和可编程性虽然会影响单个网元的性能，但是由于执行复杂网络任务和应用所需的设备和资源数目更少，SDN 架构提高了网络的整体性能。但是文章同样指出SDN 的具体实现对性能有很大的影响。

在剑桥大学、TU Berlin/T-Labs 和伦敦玛丽王后大学的Rotsos C 等人[10]开发的OFLOPS 项目中，针对SDN 交换机的性能测试，借鉴现代的多核环境，以多线程实现OFLOPS 平台。针对并行输入控制，设计多个测量模块，包括数据包生成、数据包捕捉、控制信道、SNMP 信道和时间管理器五个线程。针对测量场景对转发平面的影响，OFLOPS 平台与交换机之间除了控制信道之外，还嵌入了数据信道。针对数据包生成功能，OFLOPS 支持三种机制：用户空间、通过pktgen 模块的内核空间和基于NetFPGA 数据包生成器扩展进行硬件加速。针对数据包捕捉和时间戳，OFLOPS 同时支持pacp 库和修改的NetFPGA 设计。在此基础上，测试了行为处理、流表更新速度、流量监控和消息之间的交互这四个指标。

随后，Rotsos C 等人[11]又在OFLOPS 的基础上，加入OSNT[12]数据包生成器组成OFLOPS-Turbo 测试系统，使得端口的双向速率增加到20Gbit/s。

卡尔顿大学的Kunz T 等人[13]在光传输网络中对OpenFlow 协议与NETCONF 协议进行了对比。他们分别使用OpenFlow 协议和基于YANG 模型的NETCONF 协议连接OpenDayLight 控制器和两台跨数据中心的BIT7800 网元设备，通过请求不同的带宽请求来测试两个协议作为南向协议的性能。最后发现NETCONF 协议相对OpenFlow 协议速度更宽，所需的控制报文更少，但是OpenFlow 协议可以使数据面的链路利用率更高。

天地互连全球SDN 测试认证中心[14]于2016年10月使用测试OpenFlow 交换机产品的性能测试工具OFsuite_performance，针对SDN 交换机的性能，以Open vSwitch v2.8.0 为测试对象，测试了TABLEMISS 表项的PACKET IN 性能、非TABLE-MISS 表项的PACKET_IN 性能、流表更新和PACKET_OUT 消息吞吐/时延等多个性能指标。

中国信息通信研究院穆琙博等人分别从接口级别和网元级别提出针对测试指标。南向接口高性能测试检验南向接口在高业务负载条件下的网络接口能力，主要有两个测试指标：业务处理能力和缓存能力[15]。前者测试南向接口的最大业务吞吐量，后者测试最大缓存长度。

台湾交通大学，中原大学，台湾科技大学的林盈达等人[16]针对OpenFlow 交换机性能首次提出精细内部指标的概念，并提出精细内部指标的测试方法：镜像报文(Mirror-in-Process)、突发流量丢包(Burst-until-loss)、连续背靠背流量(Back-to-backtraffic)以及硬件超时计算空闲超时(Idle-timeoutderived-by-hard-timeout)。该团队开发测试工具开发的工具OFBench 使用五个测试用例测试了动作时间(action time), 流水线时间（pipeline time），缓存大小（buffer size），流水线效率（pipeline efficiency）和超时准确性（timeout accuracy）五个性能指标。

长沙理工大学的黎维[17]，熊兵[18]等人分别在软件定义广域网和软件定义数据中心网络中针对OpenFlow 协 议中的PACKET_IN 和PACKET_OUT两种消息延迟进行了理论分析和实验。他们分别针对两种网络环境分析了控制器集群的PACKET_IN消息和数据分组的到达过程，分别建立了分组转发性能模型。进而针对广域网环境应用M/M/n/m、M/M/1/m 排队模型，数据中心网络环境下应用L/M/n 和L/M/1 排队模型，刻画了软件定义网络系统的消息处理和分组处理性能。最后该项研究使用SDN测试认证中心的OFsuite_Performance 测试工具和Cbench[19]进行了一系列实验验证他们模型的结果，并对不同网络规模下控制器集群的部署提出了部署要求和优化建议。

国防科大的蒋越，杨翔瑞等人[20]提出了基于CPU+FPGA 架构的可配置SDN 交换机测试方案ORTF。其核心思想是利用FPGA 设计了一条通用报文处理流水线，将数据转发和南向协议流量统一处理，从而达到数据和控制报文时钟同步的目的。通过硬件标记报文时间，使用软件来将以太网报文重组，最终得到测试结果。在文中他们针对Pica8 P-3297 型交换机进行了OpenFlow 协议中Barrier 消息延迟测试，验证了该交换机Barrier 机制实现正确。

2 SDN 交换机南向协议性能测试需求分析和方案设计

本节首先结合SDN 交换机南向协议的发展趋势和公开的测试结果总结SDN 交换机南向协议性能测试需求，明确测试方案设计难点；然后给出灵活精确的SDN 交换机南向协议性能测试方案。

2.1 SDN 交换机南向协议性能测试需求和难点

本节将通过分析SDN 交换机南向协议发展特点和已有的SDN 交换机南向协议性能测试结果来得到SDN 交换机南向协议性能测试需求，明确性能测试方案设计难点。

首先是SDN 交换机南向协议的发展特点。软件定义网络架构如图1 所示，该架构分为三层：网络应用层、控制决策层和数据转发层。南向协议作为联系数据转发层和控制决策层的纽带，一方面向控制器传递交换机上报的网络状态信息，另一方面向交换机传递控制器下发的转发策略。软件定义网络从架构上确定了SDN 交换机控制决策和数据转发解耦，但是并没有指定南向协议的具体实现方式。

图1 SDN 架构Fig.1 SDN architecture

在SDN 发展初期，OpenFlow 协议是唯一的南向协议。从文献[21]中可以看到，OpenFlow 协议自2008年被提出，一直保持快速的迭代速度。开放网络基金会在2009年发布了OpenFlow 交换机规范 1.0 版本[22]，到2015年OpenFlow 已经迭代到1.5.1版本[23]。

到了SDN 发展中后期，越来越复杂的网络场景导致OpenFlow 协议流表的匹配项越来越繁杂，这给SDN 交换机硬件设计厂商带来了严峻的挑战。为了解决OpenFlow 协议带来的问题，一些厂商通过将传统协议NETCONF、BGP-LS、PCEP 与传统交换机结合，提出了具备一定软件定义能力的SDN 解决方案。同时，很多厂商开始发展自己的SDN 架构。华为推出了Protocol-oblivious forwarding（POF）[24]架构。思科推出了SDN 解决方案Cisco Application Centric Infrastructure（Cisco ACI）[25]并在2014年提出了自己的私有南向协议Opflex[26]。开放网络基金会也提出了自己的协议无关SDN 架构P4[27]。

下面介绍一些SDN 交换机南向协议性能测试结果。剑桥大学的Rotsos C 等人使用OFLOPS[10]针几种不同厂家的的OpenFlow 交换机进行了一系列测试。在报文修改延迟测试中，发现基于硬件实现的交换机延迟普遍小于10us，而基于软件实现的交换机延迟普遍在几百微秒；在流表更新延迟测试中发现想要精确感知交换机状态的变化，必须基于数据面报文转发行为来探测；在流表下发和修改延迟测试中，利用数据面的探针报文来感知流表生效的时刻，最快的交换机延迟为几百微秒，最慢的交换机延迟为几十毫秒；针对获取交换机流表状态时延测试发现流表状态获取严重依赖CPU 的性能，普遍的处理延迟大于1ms，部分交换机甚至达到了1s。

全球SDN 测试认证中心联合IXIA 等公司分别举办了2016、2017 春季SDNVF FEST 测试活动[28]。在活动中针对烽火通信、华为、Radisys、智邦科技等公司的SDN 交换机进行了相关性能测试。在流表安装速率的测试中，当控制器以1Kpps 速率下发流表时，交换机的流表安装速率最高为每秒500 条。将控制器发送速率提高到10Kpps 时，交换机的流表项安装速率最高为每秒1666 条；在PACKET_IN 上报速率测试中得到最高速率为8000pps；组表转发测试只有华为一家厂商支持，结果显示交换机转发速率能够达到网卡线速，转发延迟为98810ns。

结合SDN 交换机南向协议的发展历程和已有的SDN 交换机性能测试结果，可以看到SDN 交换机南向协议性能测试需求包含三方面：首先是良好的扩展性。南向协议发展迅速、种类多、迭代快，测试方案必须能够快速适配南向协议的快速发展；其次是方便灵活的流量构造能力。从测试结果来看吞吐量量级在每秒几千报文，这表明南向协议性能测试对探针报文的发送能力要求并不严苛。但是从测试指标来看测试过程中需要的流量场景灵活多变，这就要求测试方案必须具备方便灵活的突发流量构造能力；最后是精确的时间测量能力。从延迟测试结果来看，结果量级大多在几十微秒到几十毫秒。这就要求测试方案必须具备亚微秒的时间测量精度，才能保证延迟测试结果的准确性。

为了满足上述测试需求，SDN 交换机南向协议性能测试方案设计面临两个难点：首先是良好的可扩展性与系统复杂功能之间的矛盾。性能测试方案功能繁杂，需要包含方便灵活的控制面/数据面流量构造、发送、捕获和分析功能。如何使测试方案既能够高效执行复杂系统功能又保证良好的系统扩展性和易用性成为了系统架构设计的一大难点；其次是方便灵活的流量构造能力与精确时间测量能力之间的矛盾。软件方案可以轻松保证灵活方便的流量构造能力，但会导致报文捕获精确度严重降低。硬件方案可以极大提高报文的捕获精度，却使得流量构造十分繁琐。如何将系统功能进行合理的软硬件划分成为了系统设计的又一大难点。

2.2 灵活精确的SDN 交换机南向协议性能测试方案

图2 灵活可扩展的SDN 交换机南向协议性能测试方案Fig.2 Flexible and scalable SDN switch southbound protocol performance test scheme

为了满足2.1 节中提出的良好的系统扩展性和方便灵活的突发流量构造能力，本文提出了如图2所示的灵活可扩展的SDN 交换机南向协议性能测试方案。从测试流程来看，在进行性能测试时，用户通过控制台用户接口选择测试例。每个测试例通过自定义控制器模块与待测交换机建立控制信道，通过流量生成模块生成探针流量触发交换机的行为，通过流量捕获模块将控制和数据信道的报文按需捕获，被捕获的数据探针报文被送回测试例程序，被捕获的南向协议报文被报文重组模块重组为应用层报文后送往测试例程序，最终由测试例程序分析报文得到测试结果由控制台用户接口展示。

在灵活可扩展的SDN 交换机南向协议性能测试方案中具体包含6 个部分：控制台用户接口、测试例、自定义控制器模块、流量生成模块、流量捕获模块、自定义报文分析模块。各个模块详细功能如下所述。

控制台用户接口：与测试用户进行交互的接口。在测试过程中，用户首先在此选择要进行的测试并对相关参数进行配置，然后系统内部调用对应的测试例程序进行实际测试，最后将测试结果展示给用户。

测试例：整个测试系统的核心模块，驱动整个测试流程的进行。用户可以按需编写自己的测试例程序。测试例可以按需创建控制器实例来与待测交换机进行南向协议通信，可以通过流量生成模块按照指定发送间隔产生指定类型的流量，可以通过流量捕获模块按需抓取测试过程中的控制/数据信道的流量，可以通过自定义报文分析模块对南向协议流量进行重组，从而得到精确的控制面事件。

自定义控制器模块：负责与待测交换机进行南向协议通信，包括维持协议连接，下发自定义配置等。此模块包含两部分，下层的不可变通信模块主要负责提供TCP/UDP 通信接口，上层由用户自行扩展南向协议，最终实现灵活可变得自定义控制器模块。

流量生成模块：主要负责按照测试例配置的发送间隔生成一系列指定类型的数据流量。

流量捕获模块：负责按照测试例的配置将数据面探针报文和控制面南向协议报文全部抓取上来，然后将带有时间信息的数据面探针报文发送给测试例，将带有时间信息的控制面南向协议报文发送给自定义报文分析模块。

自定义报文分析模块：负责将带有时间信息的南向协议以太网报文恢复为带有时间信息的南向协议报文，然后发送给测试例。此模块也包含两部分，下层由不可变保温重组模块主要负责将物理层、网络层、传输层的头部去掉，恢复为带有时间戳的应用层原生报文。上层由用户自行扩展南向协议分析模块，最终获得带有时间信息的南向协议报文。

通过上面的设计，利用自定义控制器模块和自定义报文分析模块，本方案可以在不破坏整个系统测试流程的情况下，实现对不同南向协议的扩展能力，同时利用基于libnet 的软件流量生成模块，可以方便灵活的按需构造各种流量场景。至此，我们得到了一个灵活可扩展的SDN 换机南向协议性能测试方案。

为了提高测试方案的时间测量精度，本文在 图2 所示测试方案的基础上，采用软硬件结合的流量捕获方式，大幅度提高报文的捕获时间精度得到如图3 所示的灵活精确的SDN 交换机南向协议性能测试方案。

图3 灵活精确的SDN 交换机南向协议性能测试方案Fig.3 Flexible and accurate SDN switch southbound protocol performance test scheme

为了提高流量捕获模块的测量精度同时不大幅度增加系统复杂度，本方案使用FAST[29]架构开发了一个硬件支撑平台来辅助libpcap 最终实现精确度在纳秒级的报文捕获模块。硬件支撑平台主要完成南向协议/数据探针报文时间戳的获取和回传时间戳两个功能。首先是报文时间戳的精确获取，为了南向协议和数据探针报文的时间戳有可比性必须统一时钟。因此控制面南向协议和数据面探针流量都要经过同一条硬件流水线，同时在2.1 中分析得到南向协议性能测试对数据流量带宽需求并不大。因此为了简化设计，本方案在测试机中将南向协议和数据探针的流量采用同一个网卡通信，从而简化报文时间戳的获取。对于每一个进入硬件支撑平台网卡0 的报文，在其进入的时刻获取当前时钟计数即可。但是，当南向协议和数据探针流量混合在一起进入硬件支撑平台后，硬件支撑平台需要将二者区分开，分别转发给待测交换机的控制网卡和数据网卡。本方案将所有数据探针流量的目的MAC 地址设为特殊值，硬件支撑平台在0 号网卡收到流量后，只需简单判断报文的目的MAC 地址是否为特殊值即可将流量正确转发到控制网卡（1 号网卡）和数据发送网卡（2 号网卡）。解决了报文时间戳的获取问题，下一步就是要解决时间戳的回传问题。同样是为了简化设计，考虑到南向协议性能测试时对测试机网卡带宽需求并不高，本方案在硬件支撑平台收到每个报文时，截取其前64 字节生成一个新的以太网报文，并将硬件时间戳记录到报文的源MAC 地址中，通过0号网卡回传给测试机。当硬件支撑平台0 号网卡收到来自测试机的流量将摘要报文回传给测试机时便得到了报文的发送时间戳，当硬件支撑平台1 号网卡收到来自待测交换机返回的流量将摘要报文回传给测试机时，便得到了报文的接收时间。特别注意，由于数据面流量本身没有意义，本方案仅关注其转发的时间，因此硬件支撑平台3 号网卡在收到待测交换机转发的数据流量后，并没有将数据报文转发到0 号网卡，而是只将数据摘要报文发送，这样可以大幅度节约测试机和硬件支撑设备之间的通信带宽。最终通过libpcap 和硬件支撑平台相互配合得到了一个精确度为8ns 的流量捕获模块。

在图3 中由于引入硬件支撑平台，流量重组模块和测试例也要相应的变化。流量捕获模块获取报文分为三类，第一类是南向协议报文；第二类是南向协议报文的摘要报文；第三类是数据探针报文的摘要报文。在实际测试中，前两类报文被一同送入报文重组模块，得到带有精确时间戳的南向协议报文供测试例分析，数据探针的摘要报文被送入测试例。

3 关键模块设计

本节将以OpenFlow 协议为例，介绍灵活精确的SDN 交换机南向协议性能测试方案中关键模块的实现细节，包括自定义控制器、报文重组模块、基于libnet 的流量生成模块、基于libpcap 的流量捕获模块以及硬件支撑平台。

3.1 自定义OpenFlow 控制器和报文重组模块

自定义控制器的作用是与待测交换机建立南向协议通信，下发自定义配置信息，本节以OpenFlow 1.3.5 协议为例阐述自定义控制器的实现流程。如图4 所示，OpenFlow 协议工作的基本工作流程可以分为连接建立、连接维持、连接中断三个阶段。

图4 OpenFlow 协议工作流程Fig.4 OpenFlow protocol workflow

在SDN 交换机性能测试中，需要自定义OpenFlow 控制器与交换机建立控制信道，在连接维持阶段能够根据测试例的需求灵活更改交换机配置。为了能够达到上述目标，本方案设计了如图5 所示的双线程结构。在测试中，测试例程序首先创建一个自定义OpenFlow 控制器实例，在创建时可以指定控制器实例对来自交换机消息的处理方式。控制器实例被创建后，开启如图6 所示的单独线程与交换机维持OpenFlow 控制信道。在测试过程中，测试例程序调用控制器实例提供的接口向交换机下发配置信息存在两种方式：其一是异步消息，通过控制器提供的借口直接下发，不需要等待交换机回复；其二是调用控制器提供的接口发送消息的同时注册一个事件，随后测试例线程进入阻塞状态，当控制器线程收到期望消息后唤醒测试例线程。最后，当测试完成后，测试例线程通过控制器提供的接口通知并等待控制器线程退出。

图5 自定义OpenFlow 控制器工作流程Fig.5 Customize OpenFlow controller workflowrule_

图6 控制器逻辑Fig.6 Controller logic

自定义OpenFlow 报文重组模块的主要任务是读取流量捕获模块抓取的pcap 文件，将其中带有时间戳的以太网报文转换为带有时间戳的OpenFlow报文。为了实现这一目标，本文设计了analysier 和node 两个结构体组成二级结构。analysier 实例负责标识一个重组原始文件，rule_node 实例标识一个目标文件。每个analysier 实例可以携带多个rule_node实例，每个rule_node 实例只能绑定到一个analysier实例中。报文重组的过程如图7 所示，在启动重组接口之后会创建一个工作线程，该线程从pcap 文件中读取以太网报文，提取报文中的IP 五元组信息与analysis_rule_node_t 的过滤规则相比较，将符合过滤规则的报文传入对应的回调函数，最终将带有时间戳的报文信息存储到指定的临时文件中。

3.2 基于libnet 的流量生成模块

流量生成模块的主要任务是按照配置，通过指定的网卡产生一定速率的流量。在产生流量时，首先使用IP 五元组信息和发包间隔参数创建发包实例。创建实例默认是没有配置IP 五元组掩码的，如果想要发送报文的IP 五元组随机发生改变，可以调用接口进行设置。然后调用启动接口创建如图8 所示的工作线程。

图7 报文重组逻辑Fig.7 Packet reorganization logic

3.3 基于libpcap 的流量捕获模块

流量捕获模块的主要任务是根据IP 五元组信息将流经特定网卡的全部流量进行捕获。在捕获流量时，首先使用IP 五元组信息和捕获数量参数创建捕获实例。然后调用启动接口创建如图9 所示的抓包工作线程。如果需要测试线程等待抓包则调用等待接口，在工作线程结束时，会调用唤醒接口来唤醒等待线程。

图8 发包逻辑Fig.8 Sending packet logic

3.4 南向协议性能测试硬件支撑平台

如图3 所示，南向协议性能测试硬件支撑平台的主要任务包含两方面：一方面是将每个进入0 号、1 号和3 号网卡的报文产生对应的摘要报文，通过0号网卡发送给测试机。数据摘要的格式为以太网报文的前64 字节，将以太网协议类型修改为0xFF0X(最后的X 为原报文的输入网卡号)，将报文源MAC地址替换为当前的硬件时钟计数；另一方面将进入硬件支撑平台的报文根据入端口和报文类型分别转发到对应的目的端口。具体为，进入0 号网卡的报文，如果目的MAC 地址为0x0000C0000000 则认为是数据流量，将报文从2 号网卡转发，其余报文认为是南向协议报文，将报文从1 号网卡转发。进入1号网卡的报文，从0 号网卡转发。进入2 和3 号网卡的报文直接丢弃。

图9 抓包逻辑Fig.9 Capturing packet logic

为了实现上述功能，本方案使用FAST 架构。FAST 是面向多核CPU+FPGA 平台，支持互联网创新研究和计算机网络实验教学的开源项目。FAST 定义了硬件加速网络接口与操作系统内核以及用户态程序数据交互的格式和协议，基于软硬件协同设计支持网络设备数据平面快速实现。在FAST 架构中自定义硬件模块(UM)部分开发了如图10 所示的三个模块。报文缓存模块（PKT_FIFO）的作用是缓存进入UM 的报文，当模块传来读取信号时将数据读出。摘要生成模块(DGM)的作用是当报文缓存模块不为空时，从报文缓存模块中读取一个报文，生成该报文的摘要，待报文全部传输到动作转发模块后，将摘要报文也传输到动作转发模块。动作转发模块(ACM)的作用是当有报文到来时，判断该报文是否是摘要报文，如果是则直接转发；否则根据与报文对应的元信息中的入网卡和目的MAC 决定该报文的输出网卡。限于篇幅，本文不再详细介绍各个模块内部的逻辑实现。

图10 硬件支撑平台总体设计Fig.10 Overall design of hardware support platform

4 SDN 交换机性能测试实验

本节首先介绍SDN 交换机性能测试实验的测试环境，包括测试机、硬件支撑平台和待测设备的相关参数，然后针对待测交换机的OpenFlow 性能进行了一系列测试。

4.1 测试环境

将测试机、南向协议性能测试硬件支撑平台、数据转发性能测试硬件支撑平台三者相结合形成高速SDN 交换机性能测试系统，与待测交换机连接后得到如图11 所示的测试环境。

在测试过程中，测试机采用浪潮英信服务器NF5170M4，运行系统为Ubuntu16.04。南向协议性能测试硬件采用FAST 团队官方提供的OpenBox-S4平台，其基本情况为：芯片组为Zynq-7000 芯片，内置双核Cortex-A9 处理器，内存大小为为512MB，网卡接口为4 个千兆以太网数据接口和1 个千兆以太网管理接口。待测交换机型号为新华三的S5560X-34S-EI 交换机。

图11 测试环境示意图Fig.11 Test environment diagram

4.2 OpenFlow 流表性能测试

OpenFlow 流表性能测试包括流表安装延迟、修改以及删除延迟。

流表安装延迟测试的具体步骤为：

（1）删除交换机中所有流表项；

（2）持续发送数据探针报文（64 字节）到交换机的端口1，此时没有报文从端口2 转发出去；

（3）向0 号流表下发一条流表项，该流表项匹配端口1 的数据探针报文，动作为转发到2 号端口，记录下发流表的时刻为T1；

（4）流表生效后会有报文从2 号端口转发，此时停止发送报文，记录第一个转发报文的时刻为T2；

（5）计算测试结果Tdelay=T2-T1。

使用上述方案分别在0 条无关流表项和500 条无关流表项的环境下进行了100 次测试，得到图12所示的结果。从图12 中可以看到：交换机流表安装延迟性能基本稳定在6ms 左右，少数情况下交换机性能抖动导致流表安装延迟飙升到27ms。无关流表对流表安装延迟没有明显的影响。

流表安装延迟测试的具体步骤为：

（1）删除交换机中所有流表项；

（2）向0 号流表下发一条流表项，该流表项匹配端口1 的数据探针报文，动作为转发到2 号端口；

（3）持续发送数据探针报文（64 字节）到交换机的端口1，当有报文从端口2 转发出来时发送流表删除报文，记录时刻为T1；

（4）持续发送数据探针报文一段时间（5 秒），记录最后一个转发报文的时刻为T2；

（5）计算测试结果为Tdelay=T2-T1。

使用上述方案分别在0 条无关流表项和500 条无关流表项的环境下进行了100 次测试，得到图13所示的结果。

从图13 中可以看到：从整体来看，交换机流表删除延迟呈现出明显的分层现象，在20%左右的情况下产生较长的延迟是其余较短延迟的数倍；对比500 条无关流表和0 条无关流表的结果可以看到，无关流表在延迟较低部分会增加流表删除延迟大约0.5ms，在延迟较高的部分影响更大，极端情况下延迟达到27ms。

图12 流表安装延迟结果Fig.12 Flow table installation delay result

图13 流表删除延迟结果Fig.13 Flow table delete delay results

流表修改延迟测试的具体步骤为：

（1）删除交换机中所有流表项；

（2）向0 号流表下发一条流表项，该流表项匹配端口1 的数据探针报文，动作为转发到控制器;

（3）持续发送数据探针报文（64 字节）到交换机的端口1，当收到PACKET_IN 报文时，下发流表修改表项将转发端口修改为端口2，记录此时刻为T1；

（4）流表生效后会有报文从2 号端口转发，此时停止发送报文，记录第一个转发报文的时间为T2；

（5）测试结果为Tdelay=T2-T1。

使用上述方案分别在0 条无关流表项和500 条无关流表项的环境下进行了100 次测试，得到图14所示的结果。

从图14 中可以看到：流表修改延迟表现出分层现象，在10%左右的情况下产生较长的延迟是其余较短延迟的数倍；对比对比500 条无关流表和0 条无关流表的结果可以看到，无关流表项会导致流表修改延迟增加大约1.5ms。

图14 流表修改延迟结果Fig.14 Flow table modification delay result

5 展望与下一步工作

本文围绕SDN 交换机南向协议性能测试进行研究，主要包括南向协议性能测试需求分析和方案设计、系统实现三个方面。最后通过针对新华三交换机进行了OpenFlow 流表性能测试，客观的评价了该交换机的实际性能，验证了测试方案的可行性。

本文主要针对单个交换机的性能指标进行了探讨。但是随着SDN 网络的快速发展，单个设备的性能很难客观的反映整个网络的性能。后续可以继续研究如何针对具体的网络业务场景制定普适的性能指标，然后模拟出真实的SDN 网络业务流量，最终客观的评价SDN 网络的性能。

本文所提出的系统方案本质上采用的是以中间人攻击的方式将网络流量进行时间标记，在测试端恢复出报文语义，根据报文语义中代表的网络事件来得到测试结果，这就导致无法针对加密南向协议进行测试。在越来越重视信息安全的今天，如何设计针对加密南向协议性能测试方案同样值得进一步研究。

利益冲突声明

所有作者声明不存在利益冲突关系。