sdn交换机
-
2023年3月20日发(作者：汤溪水库)软件定义网络中交换机处理时延的仿真
吕怡龙;黄传河;贾永宏;张海
【摘要】针对目前的网络仿真工具在对软件定义网络(SDN)的仿真过程中,未考虑
交换机的处理时延的问题,提出一种处理时延的仿真方法,目的是为了使仿真结果更
加真实和准确.该方法首先将交换机的转发处理过程分解为对流表的查询操作和执
行不同的动作;然后,利用交换机的处理器频率和访存周期,将查询流表和执行动作转
换为处理时间.实验中测量了真实环境中不同配置的交换机处理时延,并与利用该方
法仿真出的处理时延进行对比.实验结果表明,利用该方法仿真出的处理时延和真实
交换机的处理时延基本一致,该方法能够较准确地仿真交换机处理时延.
【期刊名称】《计算机应用》
【年(卷),期】2014(034)009
【总页数】5页(P2472-2475,2509)
【关键词】软件定义网络;交换机;仿真;处理时延;流表;动作
【作者】吕怡龙;黄传河;贾永宏;张海
【作者单位】武汉大学计算机学院,武汉430000;武汉大学计算机学院,武汉
430000;武汉大学计算机学院,武汉430000;武汉大学计算机学院,武汉430000
【正文语种】中文
【中图分类】TP393
0引言
随着软件定义网络(SoftwareDefinedNetwork，SDN)技术的发展，控制平面与
数据平面的分离使SDN交换机相对于传统交换机在功能和灵活性上产生了巨大的
变革。OpenFlow初步实现了SDN的原型设计思想，推动了SDN技术的快速发
展［1－3］。
另一方面，目前已经出现了多种可针对SDN网络进行仿真的工具，如MiniNet、
EstiNet、NS－3等，这些仿真工具没有考虑SDN交换机的处理时延［4－6］。
这种方式会影响对SDN网络仿真的精确性。随着OpenFlow1.1之后多级流表的
引入，OpenFlow交换机对数据报文不再是简单的MAC层或IP层的转发，相反，
OpenFlow使交换机具备了细粒度控制的转发能力。此外，OpenFlow交换机还
具有很多其他功能，如防火墙、网络地址转换(NetworkAddressTranslation，
NAT)等，在安全领域还需处理虚拟专用网络(VirtualPrivateNetwork，VPN)［7
－9］。
为了说明处理时延的影响，首先分析一个数据包可能产生的所有时延。当数据包经
交换机转发，向另一个节点发送时，往往产生以下几个时延:
1)传播时延:数据包在链路上传输的时延。
2)处理时延:交换机对数据包的转发处理时延。
3)排队时延:数据包在发送前的缓冲时延。
4)发送时延:将数据包由接口发送到链路的时延。
表1展示了一个具有1GB/s带宽，200km长链路的网络，在转发长度为1250
B的数据包的时延情况［10］。
表1网络时延操作传播时延/μs处理时延/μs排队时延/μs发送时延/μs处理时延
占总时延的比例/%单流表简单的MAC层转发100010［0，∞)101多级流表的
复杂控制1000500［0，∞)1033
从表1可以看出，对简单的数据包转发处理时延所占总时延比重非常小，所用处
理时延相对于其他时延可以忽略。但当交换机处理操作包括防火墙、NAT、设置
虚拟局域网(VirtualLocalAreaNetwork，VLAN)号、优先级、修改源、目的端
口等多级流表控制的复杂功能时，处理时延就会大大增加。为了对SDN交换机处
理时延进行仿真，本文提出了一种较精确的SDN交换机处理时延仿真方法。
1处理时延仿真方法
1.1交换机处理时延产生分析
OpenFlow交换机拥有一个或多个流表，通过查询流表来确定对数据包的操作和
转发动作。流表中包含多个流表项，每个流表项都包含匹配规则、操作和计数三部
分。其中匹配规则由包括输入端口、源MAC地址、目的MAC地址、以太网类型、
VLAN号等在内的用来匹配分组首部信息的元组组成;操作部分记录着对分组的一
系列处理动作;计数部分是对该流表项所匹配过的分组数量及比特的统计。
当一个分组到达OpenFlow交换机时，该分组的首部信息会被提取出来并用来与
流表项进行匹配，如果交换机的流表中不存在与该分组匹配的流表项，则该分组全
部或部分被转发到控制器，并由控制器来决定如何对该分组或者此类流进行处理;
如果该分组与交换机中的流表项匹配成功，OpenFlow交换机将会按照所匹配的
流表项的操作字段的内容对分组进行转发处理［11］。OpenFlow交换机对于到
达分组的处理流程如图1所示。
图1OpenFlow交换机的处理流程
通过对OpenFlow交换机的转发处理过程的分析，可以看出处理时延主要由两部
分构成:一部分是针对数据包进行流表项查询的开销;另一部分是针对数据包的相应
动作(Actions)的执行开销，如设置VLAN号、剥离VLAN首部、修改MAC地址、
修改生存时间(TimeToLive，TTL)等。同时由交换机处理器的工作特点可知处理
器的工作时间开销也主要集中在两部分:一部分是CPU指令的执行开销，另一部分
是指令执行过程中的访存开销。本文使用一个简单的方法来描述处理开销，这个方
法只和两个因素有关:处理单个数据包所需执行的CPU指令数以及处理单个数据包
所需的访存次数。接下来的工作将分三步进行:首先，将数据包的转发过程转化为
相应的流表查询次数以及OpenFlow交换机的动作(Action)集合;其次，确定
OpenFlow交换机的流表查询操作以及执行动作集与相应CPU指令数和访存次数
的对应关系;最后，将CPU指令数与访存次数转化为处理时延。
1.2流表查询与动作集
由于SDN灵活的设计理念，即使对于同一个OpenFlow交换机，不同的配置也
会产生交换机控制粒度以及控制方式的不同，也就是说交换机内的流表个数、流表
项是和配置有关的。所以不能简单地针对同一个交换机给出其固定的流表查询次数
以及动作集，相反需要一种能适应各种交换机配置的方法来获取流表查询次数和动
作集。
1.2.1获取流表查询次数
在OpenFlow交换机中，维持着多个计数器。计数器可以针对如下结构维护:流表、
端口、队列、组、组存储段等。这些计数器用来统计流量的一些信息，例如流表项
匹配次数、流表查找次数、端口发送数据包数等。其中“查找次数”是针对每个流
表维护的，它代表交换机已转发过的所有数据包对该流表的查询次数［7］。所以
在网络仿真中，可以通过定义API动态获取每个时刻每个流表的“查询次数”。
这里使用Qcount1(i)表示在数据包到达前编号为i的流表的查询次数，Qcount2(i)
表示数据包转发后编号为i的流表的查询次数。这样交换机转发每个数据包所需的
流表查询总次数就可表示如下:
其中:n为流表的最大编号，即交换机有n+1个流表;QCounts代表转发一个数据
包所需的流表查询总次数。
1.2.2获取动作集
每个流表项中包含一组指令，当一个数据包匹配表项时指令会被执行。这些指令可
以更改数据包、动作集或使数据包继续进行流水线处理。主要指令有以下几种:
1)Apply－Actions:立即执行当前动作列表中的动作，而不改变动作集。这个指令
经常用于修改数据包且执行同类型的多个动作的时候。
2)Clear－Actions:在动作集中立即清除所有的动作。
3)Write－Actions:将指定的动作添加到当前动作集中。
4)Goto－TableID:指定流水线处理进程中的下一张流表的ID。
除了计数器之外，在OpenFlow交换机内部还为每次报文的转发维持着一个“动
作集(ActionSet)”。动作集与每个报文相关，默认情况下是空的。一个流表项可
以使用Write－Action指令或者Clear－Action指令修改动作集，动作集在流表
流水线处理过程中被累加。当一个表项的指令集没有包含Goto－Table指令时，
流水线处理结束，随后执行报文的动作集。另外，Apply－Actions指令还维护一
个动作列表(ActionList)，当执行Apply－Actions指令时，动作列表中的动作也
会被依次执行。
综上可知，交换机对数据包的操作主要通过动作集(ActionSet)和动作列表
(ActionList)中动作的执行来实现。因为在网络仿真中使用程序模拟交换机的执行
过程，所以可以在数据包的转发过程中动态获取“动作集”和“动作列表”。转发
数据包所需的全部动作由“动作集”和“动作列表”中的动作组成，可用式(2)表
示:
其中:ActionSet表示“动作集”，ActionList表示“动作列表”，Action表示
“动作集”或“动作列表”中的动作，Actions表示转发数据包所需的全部动作集
合。
1.3CPU指令数和访存次数
接下来将查表次数Qcounts和执行动作集合Actions转化为相应的CPU指令数
和访存次数。对于确定的OpenFlow交换机，每一次流表查找过程需要花费的
CPU指令数和访存次数是确定的，而对于特定类型动作的执行所需CPU指令数和
访存次数也是确定的［12］。只要确定每个查找流表过程与CPU指令数和访存次
数的对应关系以及每种类型的动作与相应CPU指令数和访存次数的对应关系，就
能够将查找流表次数和执行动作集转化为CPU指令数和访存次数。
为了测量CPU执行的指令数和访存次数，使用一种新型测量工具PacketBench
［13］。PacketBench提供了一种可编程的数据包转发仿真环境，可以方便地自
定义数据包转发处理动作，并得到执行后所消耗的CPU指令数和访存次数。分别
针对“修改MAC”、“IP转发”、“Internet协议安全性(InternetProtocol
Security，IPSec)数据加密”三个动作进行CPU指令数和访存次数的测试，其中
指令开销的测试结果如图2所示，访存开销与图2情况类似。从图中可以得到如
下结论:
1)对于每个动作所需要执行的CPU指令数，需要对净荷进行处理的动作(如IPSec
加密)相对于只对数据包首部进行处理的动作(如修改MAC)要高出几个数量级;
2)只对数据包首部进行处理的动作的指令开销趋于常量，但对于不同的目的地址的
数据包有微小的变化(可能由于不同条目在流表中的位置不同);
3)对于需要处理数据包净荷的动作(如IPSec加密)，其指令开销随数据包长度变化
呈线性增长。
图2三种动作的CPU指令开销
1.3.1CPU指令数
对于查找流表所需CPU指令数是固定的，这里用i表示，它可以由交换机提供商
提供，或由PacketBench工具测量。而每个类型的动作的执行所需CPU指令数，
可能是固定不变的，如减少IP首部的TTL;也有可能和数据包的长度有关，如
IPSecVPN中的加密、数据包的复制转发等。本文使用两个参数αa和βa来描述
动作的CPU指令开销:αa表示处理动作a所需的CPU指令数与数据包长度无关的
因素;βa表示处理动作a所需的CPU指令数与数据包长度相关的因素。
假设动作a处理长为l的报文需要花费的指令数为na(l)，则
使用PacketBench测量出常见几个动作和流表查询操作的αa、βa参数，如表2
所示。所以，转发一个数据包所需的CPU指令数Icounts可用式(4)表示:
1.3.2内存访问次数
和指令数类似，查找流表所需内存访问次数是固定的，使用j表示，它可以由交换
机提供商提供，也可以通过使用PacketBench来测量。而对于每个类型的动作的
执行所需的访存次数使用两个参数γa和δa来描述:γa表示处理动作a所需的访存
次数与数据包长度无关的因素;δa表示处理动作a所需的访存次数与数据包长度有
关的因素。
设动作a处理长为l的报文需要花费的访存次数为ma(l)，则
使用PacketBench测量出常见几个动作和流表查询操作的γa，δa参数，如表2
所示。所以，转发一个数据包所需的访存总数Mcounts可用式(6)表示:
从表2中可以看到，对于IPSec，αa和γa为负数，这是因为对于每个数据包有一
个不需要加密的首部，因此也不需要进行首部处理，即当数据包只有首部部分时，
IPSec的na(l)和ma(l)应为0。又因为l包含首部长度，所以式(3)中的βal与式(5)
中的δal都将首部处理计算在内，所以导致这两个参数为负数以抵消对首部处理
的计算。因为数据总包长度包含数据包首部长度，所以计算结果总是正值。
表2动作开销动作aαaβaγaδa1530790修改端口1890860修改MAC
1680910IP转发2050500查询流表IPSec－2363294－868104
1.4时间参数
要将公式中关于CPU指令数和访存次数的参数转变为与时间有关的参数，就要考
虑转发处理程序所处的交换机硬件环境。当今网络中所用到的OpenFlow交换机
处理器核心主要是采用精简指令集计算机(ReducedInstructionSetComputer，
RISC)指令，它们在结构上非常相似。通常情况下，一个RISC处理器一个时钟执
行一条指令。为了得到一个采用RISC的处理器的处理性能，这里使用处理器频率
f。这个参数很容易获得，而且是处理速度的一个很好的近似。因此执行Icounts
条指令所花费的处理时间tI可用式(7)表示:
其中Icounts为式(4)所求转发长度为l的数据包所需的指令数。但是RISC处理器
的处理性能会因为访存造成的流水线停顿而下降。为了将访存的因素考虑在内，假
设每次访存的访存时间为tmem，则由访存引起的时延tM可用式(8)表示:
其中Mcounts为式(6)所求转发长度为l的数据包所需的访存次数。所以，数据包
转发处理总时延tp可用式(9)表示:
2实验对比与分析
为了验证该本文仿真方法的有效性，需要将之前推导出的交换机处理时延计算方法
应用于网络仿真工具中，并与真实处理时延作对比。这里只关注具有一个交换机的
网络的处理时延。为了准确测量每个数据包的处理时延，实验中采用较低的发送速
率(2KB/s)，以减少交换机中的数据包排队，使用高速链路以使发送时延可忽略，
同时记录每个数据包进入和离开交换机的时间戳，具体实验网络结构如图3所示。
图3实验网络结构
实验中使用的SDN交换机型号为OpenxNet－5016R，控制器使用
OpenDaylight。OpenDaylight控制器使用Java编写，可以部署到任何支持
Java的平台上，同时底层支持混合模式的交换机和OpenFlow交换机。交换机处
理器频率为233MHz，每次访存时间为150ns。数据流由源主机经10MB/s以
太网链路发送，测量节点以混杂模式运行tcpdump以实现对交换机的两个接口的
数据包捕获。因为集线器不会缓存数据包，所以也就不会造成任何的时延。交换机
的处理时延由数据包经过两个接口的时间戳之差计算得到，为了保证结果的准确性，
两个接口的测量必须使用同一台主机，实验分两组进行。
第一组测试仅处理报文首部的动作与处理报文净荷的动作的时间开销。首先为交换
机配置单个流表，分别对接收到的报文进行修改MAC地址和IP转发操作;然后，
使用同样的单流表交换机，对接收到的报文进行IPSec加密处理。其中数据流是
由一系列UDP数据报组成，数据报长度依次以一定速率增大。测量的报文净荷长
度在0～1600B，因为MAC层的原因，过长的数据包也会造成分片。测量结果如
图4(a)所示。
第二组用来测试不同的流表查询次数以及单一动作和多组动作对处理时延的影响。
首先对交换机配置单流表多动作，执行动作包括修改源MAC地址、修改目的
MAC地址、修改源端口、修改目的端口、IP转发共5个动作;然后配置交换机使
其具有5个流表，每个流表中的流表项分别执行一个上述动作，即多流表多动作;
最后配置交换机使用单流表对数据报进行IP转发的单一动作，即单流表单动作。
其中数据流每次使用等长的UDP数据报，报文净荷长度同样在0～1600B取值，
进行多次测量，每次净荷长度取值不同。测试结果如图5(a)所示。
从第一组实验结果可以看到，正如期望的一样，处理时延随着数据包长度的增加有
所增长;但是发现简单的数据包转发也存在着这个规律，原因可能是需要将数据包
从一个接口复制到另一个接口。第二组实验结果也基本符合之前的分析，其中多流
表多动作的处理时延要大于单流表多动作，说明流表的查询是需要消耗一定时延的;
而单流表多动作的处理时延又大于单流表单动作的处理时延，这说明动作的多少也
决定着处理时延。将处理时延计算方式应用于MiniNet网络仿真工具，同样采用
图3的网络结构，用上述推导出的公式及表2中的测量参数估算出一个时延增加
于网络仿真中，并与测量结果进行比较，结果如图4(b)和图5(b)。可以看出仿真
结果和实际测量结果具有很大相似度，说明本文的计算方法能够较真实地对SDN
交换机的处理时延进行仿真。
图4第一组实验测量结果
图5第二组实验测量结果
3结语
本文通过对SDN交换机工作过程的分析，提出了一种SDN交换机处理时延的仿
真方法。该方法考虑了影响处理时延的两个重要因素:与数据包长度无关因素以及
与数据包长度相关因素。实验通过测量真实环境下不同情况的处理时延，并与本文
方法的仿真结果进行对比，验证了本文方法能够较准确地对SDN交换机处理时延
进行仿真。针对本文方法的验证尚存在一些不足之处:只对小型的仅有几跳的网络
进行了测试，在今后的工作中要进一步研究更大规模网络中的交换机处理时延，以
验证本方法的适用性。
参考文献:
［1］ZHANGS，onsoftwaredefinednetworkresearch
［J］.ApplicationResearchofComputers，2013，30(8):2246－2251.(张顺
淼，邹复民.软件定义网络研究综述［J］.计算机应用研究，2013，30(8):2246－
2251.)
［2］YEGANEHSH，TOOTOONCHIANA，abilityof
software－definednetworking［J］.IEEECommunicationsMagazine，
2013，51(2):136－141.
［3］VAUGHAN－ow:Thenextgenerationofthe
network？［J］.Computer，2011，44(8):13－15.
［4］GUPTAM，SOMMERSJ，，accuratesimulation
forSDNprototyping［C］//SIGCOMM2013:Proceedingsofthe2013
k:ACM，2013:31－
36.
［5］WANGSY，CHOUCL，tOpenFlownetwork
simulatorandemulator［J］.IEEECommunicationsMagazine，2013，
51(9):110－117.
［6］PONGRACZG，MOLNARL，ngroadblocksfrom
SDN:OpenFlowsoftwareswitchperformanceonIntelDPDK［C］//EWSDN
2013:Proceedingsofthe2013SecondEuropeanWorkshoponSoftware
away:IEEE，2013:62－67.
［7］FARIASF，SALVATTIJ，VICTORP，atinglegacy
forwardingenvironmenttoOpenFlow/SDNcontrolplane［C］//APNOMS
2013:Proceedingsofthe2013AsiaPacificNetworkOpera－
［8］FUKUDAI，mentofOpenFlow/SDNtechnologiesto
carrierservices［J］.IEICETransactionsonCommunications，2013，
96(12):2946－2952.
［9］RENT，isofthenewfeaturesofOpenFlow1.4［C］
//ICITSM2013:Proceedingsofthe20132ndInternationalConferenceon
InformationTechnology，System＆dam:Atlantis
Press，2014:73－77.
［10］ROYA，YOCUMK，ngesintheemulationof
largescalesoftwaredefinednetworks［C］//APSYS2013:Proceedingsof
the20134thAsia－k:ACM，2013:10
－16.
［11］JIANGP，CHENM，ingperformanceoftheOpen－
Flowsoftwareswitch［J］.JournalofChongqingUniversityofPostsand
Telecommunications:NaturalScienceEdition，2013，25(1):24－29.(蒋培成，
陈鸣，李兵.OpenFlow软交换机的性能测量［J］.重庆邮电大学学报:自然科学版，
2013，25(1):24－29.)
［12］CANINIM，VENZANOD，PEREŠÍNIP，aytotest
OpenFlowapplications［C］//NSDI2012:Proceedingsofthe20129th
USENIXSymposiumonNetworkedSystemsDesignand
ey:USENIXAssociation，2012:10.
［13］SALEHIME，FAKHRAIESM，ction
setarchitecturalguidelinesforembeddedpacket－processingengines
［J］.JournalofSystemsArchitecture，2012，58(3):112－125.