,1, 李津,2, 虞红芳,3,*, 孙罡,3A Flexible and Accurate SDN Switch Southbound Protocol Performance Test System
Zhang Yifan,1, Li Jin,2, Yu Hongfang,3,*, Sun Gang,3通讯作者: * 虞红芳（E-mail:yuhf@uestc.edu.cn）
收稿日期:2020-04-10网络出版日期:2020-08-20
Received:2020-04-10Online:2020-08-20
作者简介 About authors
张一凡,中国电子科技集团公司第五十四研究所,硕士,助理工程师。2020年毕业于电子科技大学通信与信息系统专业,获工学硕士学位。主要研究方向为软件定义网络、数据中心网络。
本文主要承担工作为系统方案设计、实现和论文写作。
Zhang Yifan is an assistant engineer at The 54th Research Institute of China Electronics Technology Group Corporation. He received his M.S. degree in Communication and Information Engineering in 2020 from UESTC. His current research interests include software defined networking and data center networking.
In this paper he is mainly responsible for the system design, implementation and paper writing.
E-mail:
李津,信息系统安全技术国家重点实验室,硕士,工程师。2006年毕业于国防科技大学,获工学硕士学位。主要研究方向为信息安全、网络安全。
本文主要承担工作为系统方案设计指导。
Li Jin is an engineer at Nation Key Laboratory of Science and Technology on Information System Security (STISS). He received his M.S. degree in Computer Science and Technology in 2006 from NUDT. His current research interests include information security and network security.
In this paper he is mainly responsible for the system design guidance.
E-mail:
虞红芳,电子科技大学信息与通信工程学院,博士,教授。2012年毕业于电子科技大学通信与信息系统专业,获工学博士学位。主要研究方向为网络虚拟化、云/边缘计算、分布式人工智能、区块链。
本文主要承担工作为技术方案和论文写作指导。
Yu Hongfang is a professor at School of Communication and Information Engineering of University of Electronic Science and Technology of China (UESTC). She received her M.S. degree and Ph.D. degree in Communication and Information Engineering in 1999 and 2006 from UESTC, respectively. Her current research interests include data center networking, network (function) virtualization, cloud/edge computing, distributed AI and blockchain.
In this paper he is mainly responsible for the guidance of technical solutions and paper writing.
E-mail:
孙罡,电子科技大学信息与通信工程学院,博士,副教授。2012年毕业于电子科技大学通信与信息系统专业,获工学博士学位。2012年12月至今,在电子科技大学任教。长期致力于网络虚拟化、云计算、物联网与网络信息安全领域的相关研究。
本文主要承担工作为技术方案和论文写作指导。
Sun Gang is an associate professor at School of Communication and Information Engineering of University of Electronic Science and Technology of China (UESTC). He received his Ph.D. degree in Communication and Information Engineering in 2012 from University of Electronic Science and Technology of China. His research interests include network virtualization, cloud computing, IoT and cyber security.
In this paper he is mainly responsible for the technical guidance and paper writing.
E-mail:
摘要
【目的】SDN交换机南向协议性能测试系统致力于通过构造测试场景,按照一定的流量策略探测被测交换机各项性能指标,评价其是否满足用户性能需求。【文献范围】本文重点调研了SDN交换机南向协议的发展历程、公开的SDN交换机性能测试结果以及相关SDN交换机性能测试文献等。【方法】本文给出一种灵活精确的SDN交换机南向协议性能测试系统,采用软硬件结合的架构保证了系统良好的可扩展性、灵活的流量构造能力以及纳秒级的时间测量精度。【结果】基于FAST架构,本文以OpenFlow协议为例实现了灵活精确的SDN交换机南向协议性能测试系统,并针对新华三交换机进行了一系列OpenFlow协议性能测试。【局限】本文所提出的方案仅适用于单个交换机无加密南向协议的性能测试,针对SDN交换机集群性能测试所需的场景模拟以及加密南向协议的解密突破仍需进一步探索。【结论】通过针对新华三交换机进行了OpenFlow流表性能测试,客观的评价了该交换机的实际性能,验证了本测试系统的可用性。
关键词：
Abstract
[Objective] The SDN switch southbound protocol performance testing system is dedicated to constructing test scenarios, detecting various performance indicators of the switch under test according to a certain traffic strategy, and evaluating whether it meets user performance requirements. [Scope of the literature] This article focuses on the development history of the SDN switch southbound protocols, the published SDN switch performance test results, and related SDN switch performance test literature, etc. [Methods] A flexible and accurate SDN switch southbound protocol performance test system is proposed in this article. A hardware/software co-design architecture is used to ensure scalability of the system, flexible flow construction capability, and nanosecond-level time measurement accuracy. [Results] Based on the FAST architecture, a flexible and accurate SDN switch southbound protocol performance test system for OpenFlow protocol is implemented. This system has conducted a series of OpenFlow protocol performance tests to a H3C switch. [Limitations] The scheme proposed in this article is only applicable to the performance test of a single switch without encryption southbound protocol. The scenario simulation required for SDN switch cluster performance test and the decryption breakthrough of encrypted southbound protocol still need to be further explored. [Conclusions] Through the OpenFlow flow table performance test of the H3C switch, the actual performance of the switch is objectively evaluated, and the availability of this test system is verified.
Keywords：
PDF (13507KB)元数据多维度评价相关文章导出EndNote|Ris|Bibtex收藏本文
本文引用格式
张一凡, 李津, 虞红芳, 孙罡. 一种灵活精确的SDN交换机南向协议性能测试系统. 数据与计算发展前沿[J], 2020, 2(4): 28-43 doi:10.11871/jfdc.issn.2096-742X.2020.04.003
Zhang Yifan, Li Jin, Yu Hongfang, Sun Gang.
开放科学标识码（OSID）
引言
软件定义网络（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为测试对象,测试了TABLE-MISS表项的PACKET IN性能、非TABLE-MISS表项的PACKET_IN性能、流表更新和PACKET_OUT 消息吞吐/时延等多个性能指标。
中国信息通信研究院穆琙博等人分别从接口级别和网元级别提出针对测试指标。南向接口高性能测试检验南向接口在高业务负载条件下的网络接口能力,主要有两个测试指标：业务处理能力和缓存能力[15]。前者测试南向接口的最大业务吞吐量,后者测试最大缓存长度。
台湾交通大学,中原大学,台湾科技大学的林盈达等人[16]针对OpenFlow交换机性能首次提出精细内部指标的概念,并提出精细内部指标的测试方法：镜像报文(Mirror-in-Process)、突发流量丢包(Burst-until-loss)、连续背靠背流量(Back-to-back-traffic)以及硬件超时计算空闲超时(Idle-timeout-derived-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
新窗口打开|下载原图ZIP|生成PPT图1SDN架构
Fig.1SDN 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.1节中提出的良好的系统扩展性和方便灵活的突发流量构造能力,本文提出了如图2所示的灵活可扩展的SDN交换机南向协议性能测试方案。从测试流程来看,在进行性能测试时,用户通过控制台用户接口选择测试例。每个测试例通过自定义控制器模块与待测交换机建立控制信道,通过流量生成模块生成探针流量触发交换机的行为,通过流量捕获模块将控制和数据信道的报文按需捕获,被捕获的数据探针报文被送回测试例程序,被捕获的南向协议报文被报文重组模块重组为应用层报文后送往测试例程序,最终由测试例程序分析报文得到测试结果由控制台用户接口展示。图2
新窗口打开|下载原图ZIP|生成PPT图2灵活可扩展的SDN交换机南向协议性能测试方案
Fig.2Flexible and scalable SDN switch southbound protocol performance test scheme
在灵活可扩展的SDN交换机南向协议性能测试方案中具体包含6个部分：控制台用户接口、测试例、自定义控制器模块、流量生成模块、流量捕获模块、自定义报文分析模块。各个模块详细功能如下所述。
控制台用户接口：与测试用户进行交互的接口。在测试过程中,用户首先在此选择要进行的测试并对相关参数进行配置,然后系统内部调用对应的测试例程序进行实际测试,最后将测试结果展示给用户。
测试例：整个测试系统的核心模块,驱动整个测试流程的进行。用户可以按需编写自己的测试例程序。测试例可以按需创建控制器实例来与待测交换机进行南向协议通信,可以通过流量生成模块按照指定发送间隔产生指定类型的流量,可以通过流量捕获模块按需抓取测试过程中的控制/数据信道的流量,可以通过自定义报文分析模块对南向协议流量进行重组,从而得到精确的控制面事件。
自定义控制器模块：负责与待测交换机进行南向协议通信,包括维持协议连接,下发自定义配置等。此模块包含两部分,下层的不可变通信模块主要负责提供TCP/UDP通信接口,上层由用户自行扩展南向协议,最终实现灵活可变得自定义控制器模块。
流量生成模块：主要负责按照测试例配置的发送间隔生成一系列指定类型的数据流量。
流量捕获模块：负责按照测试例的配置将数据面探针报文和控制面南向协议报文全部抓取上来,然后将带有时间信息的数据面探针报文发送给测试例,将带有时间信息的控制面南向协议报文发送给自定义报文分析模块。
自定义报文分析模块：负责将带有时间信息的南向协议以太网报文恢复为带有时间信息的南向协议报文,然后发送给测试例。此模块也包含两部分,下层由不可变保温重组模块主要负责将物理层、网络层、传输层的头部去掉,恢复为带有时间戳的应用层原生报文。上层由用户自行扩展南向协议分析模块,最终获得带有时间信息的南向协议报文。
通过上面的设计,利用自定义控制器模块和自定义报文分析模块,本方案可以在不破坏整个系统测试流程的情况下,实现对不同南向协议的扩展能力,同时利用基于libnet的软件流量生成模块,可以方便灵活的按需构造各种流量场景。至此,我们得到了一个灵活可扩展的SDN换机南向协议性能测试方案。
为了提高测试方案的时间测量精度,本文在图2所示测试方案的基础上,采用软硬件结合的流量捕获方式,大幅度提高报文的捕获时间精度得到如图3所示的灵活精确的SDN交换机南向协议性能测试方案。
图3
新窗口打开|下载原图ZIP|生成PPT图3灵活精确的SDN交换机南向协议性能测试方案
Fig.3Flexible 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
新窗口打开|下载原图ZIP|生成PPT图4OpenFlow协议工作流程
Fig.4OpenFlow protocol workflow
在SDN交换机性能测试中,需要自定义OpenFlow控制器与交换机建立控制信道,在连接维持阶段能够根据测试例的需求灵活更改交换机配置。为了能够达到上述目标,本方案设计了如图5所示的双线程结构。在测试中,测试例程序首先创建一个自定义OpenFlow控制器实例,在创建时可以指定控制器实例对来自交换机消息的处理方式。控制器实例被创建后,开启如图6所示的单独线程与交换机维持OpenFlow控制信道。在测试过程中,测试例程序调用控制器实例提供的接口向交换机下发配置信息存在两种方式：其一是异步消息,通过控制器提供的借口直接下发,不需要等待交换机回复;其二是调用控制器提供的接口发送消息的同时注册一个事件,随后测试例线程进入阻塞状态,当控制器线程收到期望消息后唤醒测试例线程。最后,当测试完成后,测试例线程通过控制器提供的接口通知并等待控制器线程退出。
图5
新窗口打开|下载原图ZIP|生成PPT图5自定义OpenFlow控制器工作流程
Fig.5Customize OpenFlow controller workflow
图6
新窗口打开|下载原图ZIP|生成PPT图6控制器逻辑
Fig.6Controller logic
自定义OpenFlow报文重组模块的主要任务是读取流量捕获模块抓取的pcap文件,将其中带有时间戳的以太网报文转换为带有时间戳的OpenFlow报文。为了实现这一目标,本文设计了analysier和rule_node两个结构体组成二级结构。analysier实例负责标识一个重组原始文件,rule_node实例标识一个目标文件。每个analysier实例可以携带多个rule_node实例,每个rule_node实例只能绑定到一个analysier实例中。报文重组的过程如图7所示,在启动重组接口之后会创建一个工作线程,该线程从pcap文件中读取以太网报文,提取报文中的IP五元组信息与analysis_rule_node_t的过滤规则相比较,将符合过滤规则的报文传入对应的回调函数,最终将带有时间戳的报文信息存储到指定的临时文件中。
图7
新窗口打开|下载原图ZIP|生成PPT图7报文重组逻辑
Fig.7Packet reorganization logic
3.2 基于libnet的流量生成模块
流量生成模块的主要任务是按照配置,通过指定的网卡产生一定速率的流量。在产生流量时,首先使用IP五元组信息和发包间隔参数创建发包实例。创建实例默认是没有配置IP五元组掩码的,如果想要发送报文的IP五元组随机发生改变,可以调用接口进行设置。然后调用启动接口创建如图8所示的工作线程。图8
新窗口打开|下载原图ZIP|生成PPT图8发包逻辑
Fig.8Sending packet logic
3.3 基于libpcap的流量捕获模块
流量捕获模块的主要任务是根据IP五元组信息将流经特定网卡的全部流量进行捕获。在捕获流量时,首先使用IP五元组信息和捕获数量参数创建捕获实例。然后调用启动接口创建如图9所示的抓包工作线程。如果需要测试线程等待抓包则调用等待接口,在工作线程结束时,会调用唤醒接口来唤醒等待线程。图9
新窗口打开|下载原图ZIP|生成PPT图9抓包逻辑
Fig.9Capturing packet logic
3.4 南向协议性能测试硬件支撑平台
如图3所示,南向协议性能测试硬件支撑平台的主要任务包含两方面：一方面是将每个进入0号、1号和3号网卡的报文产生对应的摘要报文,通过0号网卡发送给测试机。数据摘要的格式为以太网报文的前64字节,将以太网协议类型修改为0xFF0X(最后的X为原报文的输入网卡号),将报文源MAC地址替换为当前的硬件时钟计数;另一方面将进入硬件支撑平台的报文根据入端口和报文类型分别转发到对应的目的端口。具体为,进入0号网卡的报文,如果目的MAC地址为0x0000C0000000则认为是数据流量,将报文从2号网卡转发,其余报文认为是南向协议报文,将报文从1号网卡转发。进入1号网卡的报文,从0号网卡转发。进入2和3号网卡的报文直接丢弃。为了实现上述功能,本方案使用FAST架构。FAST是面向多核CPU+FPGA平台,支持互联网创新研究和计算机网络实验教学的开源项目。FAST定义了硬件加速网络接口与操作系统内核以及用户态程序数据交互的格式和协议,基于软硬件协同设计支持网络设备数据平面快速实现。在FAST架构中自定义硬件模块(UM)部分开发了如图10所示的三个模块。报文缓存模块（PKT_FIFO）的作用是缓存进入UM的报文,当模块传来读取信号时将数据读出。摘要生成模块(DGM)的作用是当报文缓存模块不为空时,从报文缓存模块中读取一个报文,生成该报文的摘要,待报文全部传输到动作转发模块后,将摘要报文也传输到动作转发模块。动作转发模块(ACM)的作用是当有报文到来时,判断该报文是否是摘要报文,如果是则直接转发;否则根据与报文对应的元信息中的入网卡和目的MAC决定该报文的输出网卡。限于篇幅,本文不再详细介绍各个模块内部的逻辑实现。
图10
新窗口打开|下载原图ZIP|生成PPT图10硬件支撑平台总体设计
Fig.10Overall design of hardware support platform
4 SDN交换机性能测试实验
本节首先介绍SDN交换机性能测试实验的测试环境,包括测试机、硬件支撑平台和待测设备的相关参数,然后针对待测交换机的OpenFlow性能进行了一系列测试。4.1 测试环境
将测试机、南向协议性能测试硬件支撑平台、数据转发性能测试硬件支撑平台三者相结合形成高速SDN交换机性能测试系统,与待测交换机连接后得到如图11所示的测试环境。图11
新窗口打开|下载原图ZIP|生成PPT图11测试环境示意图
Fig.11Test environment diagram
在测试过程中,测试机采用浪潮英信服务器NF5170M4,运行系统为Ubuntu16.04。南向协议性能测试硬件采用FAST团队官方提供的OpenBox-S4平台,其基本情况为：芯片组为Zynq-7000芯片,内置双核Cortex-A9处理器,内存大小为为512MB,网卡接口为4个千兆以太网数据接口和1个千兆以太网管理接口。待测交换机型号为新华三的S5560X-34S-EI交换机。
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。无关流表对流表安装延迟没有明显的影响。
图12
新窗口打开|下载原图ZIP|生成PPT图12流表安装延迟结果
Fig.12Flow table installation delay result
流表安装延迟测试的具体步骤为：
（1）删除交换机中所有流表项;
（2）向0号流表下发一条流表项,该流表项匹配端口1的数据探针报文,动作为转发到2号端口;
（3）持续发送数据探针报文（64字节）到交换机的端口1,当有报文从端口2转发出来时发送流表删除报文,记录时刻为T1;
（4）持续发送数据探针报文一段时间（5秒）,记录最后一个转发报文的时刻为T2;
（5）计算测试结果为 Tdelay = T2-T1。
使用上述方案分别在0条无关流表项和500条无关流表项的环境下进行了100次测试,得到图13所示的结果。
图13
新窗口打开|下载原图ZIP|生成PPT图13流表删除延迟结果
Fig.13Flow table delete delay results
从图13中可以看到：从整体来看,交换机流表删除延迟呈现出明显的分层现象,在20%左右的情况下产生较长的延迟是其余较短延迟的数倍;对比500条无关流表和0条无关流表的结果可以看到,无关流表在延迟较低部分会增加流表删除延迟大约0.5ms,在延迟较高的部分影响更大,极端情况下延迟达到27ms。
流表修改延迟测试的具体步骤为：
（1）删除交换机中所有流表项;
（2）向0号流表下发一条流表项,该流表项匹配端口1的数据探针报文,动作为转发到控制器;
（3）持续发送数据探针报文（64字节）到交换机的端口1,当收到PACKET_IN报文时,下发流表修改表项将转发端口修改为端口2,记录此时刻为T1;
（4）流表生效后会有报文从2号端口转发,此时停止发送报文,记录第一个转发报文的时间为T2;
（5）测试结果为 Tdelay = T2-T1。
使用上述方案分别在0条无关流表项和500条无关流表项的环境下进行了100次测试,得到图14所示的结果。
图14
新窗口打开|下载原图ZIP|生成PPT图14流表修改延迟结果
Fig.14Flow table modification delay result
从图14中可以看到：流表修改延迟表现出分层现象,在10%左右的情况下产生较长的延迟是其余较短延迟的数倍;对比对比500条无关流表和0条无关流表的结果可以看到,无关流表项会导致流表修改延迟增加大约1.5ms。
5 展望与下一步工作
本文围绕SDN交换机南向协议性能测试进行研究,主要包括南向协议性能测试需求分析和方案设计、系统实现三个方面。最后通过针对新华三交换机进行了OpenFlow流表性能测试,客观的评价了该交换机的实际性能,验证了测试方案的可行性。本文主要针对单个交换机的性能指标进行了探讨。但是随着SDN网络的快速发展,单个设备的性能很难客观的反映整个网络的性能。后续可以继续研究如何针对具体的网络业务场景制定普适的性能指标,然后模拟出真实的SDN网络业务流量,最终客观的评价SDN网络的性能。
本文所提出的系统方案本质上采用的是以中间人攻击的方式将网络流量进行时间标记,在测试端恢复出报文语义,根据报文语义中代表的网络事件来得到测试结果,这就导致无法针对加密南向协议进行测试。在越来越重视信息安全的今天,如何设计针对加密南向协议性能测试方案同样值得进一步研究。
利益冲突声明
所有作者声明不存在利益冲突关系。参考文献 原文顺序
文献年度倒序
文中引用次数倒序
被引期刊影响因子
[EB/ OL]. [2020-3-23].https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf.
URL [本文引用: 1]
[EB/OL]. [2020-03-23]. https://www.ietf.org/rfc/rfc1242.txt.
URL [本文引用: 1]
[EB/OL].[2020-03-23]. .
URL [本文引用: 1]
[J].
[本文引用: 1]
[EB/OL]. [2020-03-24]. https://tools.ietf.org/html/rfc4741.
URL [本文引用: 1]
[EB/OL]. [2020-03-27].https://tools.ietf.org/html/rfc7047.
URL [本文引用: 1]
[EB/OL].[2020-03-27]. https://www.rfc-editor.org/info/rfc5440.
URL [本文引用: 1]
[J].
[本文引用: 1]
[本文引用: 1]
[J].
[本文引用: 2]
[本文引用: 1]
[J].
[本文引用: 1]
[本文引用: 1]
[EB/OL].[2020-04-05]. https://www.sdnctc.com/download/resource_download/id/6.
URL [本文引用: 1]
[J].
[本文引用: 1]
[J].
[本文引用: 1]
[D].
[本文引用: 1]
[J].
[本文引用: 1]
[CP/OL]. [
URL [本文引用: 1]
[本文引用: 1]
[EB/OL]. [
URL [本文引用: 1]
[EB/OL]. [2020-04-05]. https://www.opennetworking.org/wp-content/uploads/2013/04/openflow-spec-v1.0.0.pdf.
URL [本文引用: 1]
[EB/OL]. [2020-04-05]. https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf.
URL [本文引用: 1]
[本文引用: 1]
[J].
[本文引用: 1]
[EB/OL]. [2020-04-05]. https://tools.ietf.org/html/draft-smith-opflex-00.
URL [本文引用: 1]
[J].
[本文引用: 1]
[2020-04-05]. https://www.sdnctc.com/download/resource_download/id/6.
URL [本文引用: 1]
[本文引用: 1]
