隧道上网卡设备

第卷第期计算机学报Vol.
No.
20年月CHINESEJOURNALOFCOMPUTERS.
20收稿日期:年-月-日;最终修改稿收到日期:年-月-日.
本课题得到国家"十三五"重点研发计划"网络空间安全"专项项目(2017YFB0801701)、国家自然科学基金项目(61472213)资助.
张克尧,男,1993年生,硕士研究生,主要研究领域为域间SDN互联机制、SDN数据平面可编程,E-mail:zhang-ky15@mails.
tsinghua.
edu.
cn.
毕军(通讯作者),男,1972年生,博士,教授,博士生导师,主要研究领域为SDN,源地址验证,域间路由协议,E-mail:junbi@tsinghua.
edu.
cn.
王旸旸,男,1979年生,博士后,主要研究领域为计算机网络体系结构、互联网测量,E-mail:wangyy@cernet.
edu.
cn.
第1作者手机号码:15652965919,E-mail:zhang-ky15@mails.
tsinghua.
edu.
cnOpenvSwitch中基于匹配转发表的IP隧道张克尧1),2),3)毕军1),2),3)王旸旸1),3)1)(清华大学信息网络科学与网络空间研究院,北京100084)2)(清华大学计算机科学与技术系,北京100084)3)(清华大学信息技术国家实验室,北京100084)摘要当前基于IP层的隧道技术在网络虚拟化、构建覆盖网络、连接异构网络等方面有着广泛的应用,但在管理配置方面存在不易维护、管理复杂、效率低等问题.
软件定义网络提供了开放统一的编程接口,大大提升了网络的管理效率.
但作为软件定义网络的重要标准,OpenFlow原生并不支持IP隧道的建立,因此在SDN网络中建立隧道依然依赖于传统的配置方式.
本文采用SDN中数据平面的匹配转发表编程模型,提出了一种新的IP隧道工作模式——MAT隧道.
MAT隧道可以通过下发流表规则对隧道报文直接进行封装和解封,而不再通过配置隧道端口的方式.
本文基于开源软件交换机OpenvSwitch和开源控制器Floodlight完成了MAT隧道原型的实现,并根据真实拓扑搭建了仿真环境,对MAT隧道与OpenvSwitch原有的隧道进行了对比评估,结果显示MAT隧道可以将隧道的平均时延降低10%左右,而通过隧道进行路径切换的测试表明,MAT隧道可以有效降低路径切换中的时延抖动和吞吐量的损失.
关键词软件定义网络;OpenFlow;IP隧道技术;覆盖网络;网络虚拟化;OpenvSwitch中图法分类号TP393DOI号*投稿时不提供DOI号*TunnelingoverIPbasedonMatch-ActionTableinOpenvSwitchZHANGKeyao1),2),3)BIJun1),2),3)WANGYangyang1),3)1)(InstituteforNetworkSciencesandCyberspace,TsinghuaUniversity,Beijing100084,China)2)(DepartmentofComputerScience,TsinghuaUniversity,Beijing100084,China)3)(TsinghuaNationalLaboratoryforInformationScienceandTechnology(TNList),Beijing100084,China)AbstractTunnelingoverIPhasbeenwidelyusedinthefieldofnetworkvirtualization,overlaynetwork,heterogeneousnetworkandsoon.
Nonetheless,thereexistsmaintenancedifficulty,managementcomplexity,lowefficiencyinmanagementandconfiguration.
SDNprovidesopenandunifiedAPIs,whichgreatlysimplifiesandenhancesthenetworkmanagementefficiency.
However,asasignificantsouthboundinterface,OpenFlowdoesnotprimitivelysupporttheestablishmentofIPtunnels,thereforeitstillreliesontraditionalmanualconfigurations.
Inthispaper,weadoptMatch-ActionTableprogrammingmodelofdataplane,proposinganewIPtunnelmodel,calledtheMATtunnel.
TheMATtunnelcanencapsulateanddecapsulatedirectlybyinstallingflowrulesinsteadofmanuallyconfiguringtunnelports.
WeimplementtheMATtunnelprototypebasedonOpenvSwitchandFloodlightandconstructasimulationenvironmentbasedonarealtopology.
Comparingtraditionaltunnels,wefindthattheMATtunnelcanreducetheaveragedelayby10percent.
Inaddition,thetunnelpathswitchingtestssuggestthattheMATtunnelcansignificantlydecreasethedelayjitterandthroughputloss.
KeywordsSoftwareDefinedNetworks;OpenFlow;TunnelingoverIP;OverlayNetwork;NetworkVirtualization;OpenvSwitch2计算机学报2017年1引言IP隧道技术是一种数据包封装技术,它是将原始数据包封装在另一个IP报文的载荷中进行传输.
IP隧道技术在网络环境中有广泛的应用.
例如,IP隧道技术用于网络虚拟化环境中,起到隔离用户和资源的作用[1];在互联网上通过隧道技术建立覆盖网络[2][3],提高端到端路径性能;通过隧道跨越底层物理网络,连接与底层网络异构的新型网络(比如ICN[4]、IPv6网络等).
然而传统IP隧道在管理配置方面存在管理复杂、效率低等问题.
软件定义网络(SoftwareDefinedNetworks,SDN)是一种新型网络管控体系结构,它将网络的控制和管理逻辑从设备中抽离出来,并向用户提供开放的可编程接口从而加速网络的创新[5].
由于SDN的数据平面提供了开放统一的编程接口,这大大提升了网络的管理效率.
近年来,SDN在校园网、企业网、数据中心等都得到了广泛的应用.
在SDN中,隧道的建立和管理是重要的应用需求(比如SDN方式的数据中心网络虚拟化).
但作为SDN的重要标准,OpenFlow[6]只支持基于标签的隧道(例如MPLS),而并不支持IP隧道的建立.
这使得OpenFlow在网络应用和功能的支持上,以及基于OpenFlow技术的SDN网络本身的扩展上都受到了很多限制.
现有研究为了支持IP隧道技术,在OpenFlow交换机的实现中引入了额外的机制去支持IP隧道建立,例如在软件交换机OpenvSwitch(OVS)[7]中引入了OVSDB[8]的方式支持IP隧道.
OVS以建立隧道端口的方式建立IP隧道,并在隧道端口存储隧道相关的配置信息.
用户需要通过手动或者与交换机相关的接口配置IP隧道.
这种方式带来了三个主要问题.
第一,配置复杂.
不同交换机会存在配置接口和需求的差异,手工配置的方式不仅效率低下而且容易出错;第二,这些IP隧道难以维护.
控制器并不能获得这些IP隧道的状态配置信息;第三,缺乏灵活性.
在SDN网络中隧道动态性高的场景下,隧道的建立和拆除需要在流表之外的接口实现,网络运行者需要同时控制多套编程接口(流表、不同交换机的不同远程配置接口),因此不够灵活、管控效率低.
为了解决SDN网络中IP隧道存在的问题,我们基于SDN数据平面提供的匹配转发表(Match-ActionTable,MAT)编程模型,提出了一种IP隧道模式——MAT隧道,并且在开源软件交换机OVS完成了基于MAT模型的VxLAN[9]和GRE[10]隧道实现.
本文的主要贡献包括:1、提出了一种基于匹配转发表的隧道模型,该模型中隧道通过下发流表规则对数据包直接进行隧道报文的封装和解封.
该模型允许控制器通过安装流表的方式指定封装和解封的动作以及隧道相关的参数,而不是通过配置隧道端口的方式实现.
在报文匹配相关流表之后,交换机根据指定的参数执行隧道相关的动作,然后将报文直接转发到下一跳.
2、针对MAT隧道提出了对应的基于控制器的ARP代理.
保证了MAT隧道能够正确的工作,并通过集中管控的控制器避免了ARP洪泛的问题.
3、我们根据真实拓扑搭建了仿真网络环境,在延迟和吞吐方面对比评估了MAT隧道和OVS标准配置方式的隧道.
实验结果表明MAT隧道可以降低转发延迟、提高转发效率.
相比于配置隧道,MAT模式建立隧道更快,能降低链路故障损失.
2相关工作IP隧道技术在云服务提供商和企业的数据中心网络中得到了广泛应用[11].
通过隧道封装,数据中心内为不同租户或者不同应用构建虚拟覆盖网络,实现不同租户不同应用的组网互连、网络(空间和资源)隔离、虚拟主机自由编址和移动.
实现网络虚拟化的隧道技术包括工业界广泛支持的VxLAN技术.
VxLAN隧道把二层Ethernet帧封装在IP-UDP报文载荷里.
微软开发了NVGRE[12]技术.
它利用GRE头部携带24位的虚拟子网标识符信息(VSID).
互联网国际标准组织IETF专门成立NVO3工作组,研究数据中心网络内构建虚拟网络的协议或者扩展协议标准.
比如正在进行的一般化网络虚拟化封装协议Geneve[13],以及对VxLAN的扩展[14],支持多协议封装.
IP隧道技术也用于分布在不同地理位置的数据中心之间,构建跨网域的数据中心之间的广域网(WAN)互联.
比如Google构建的B4网络[15].
B4网络连接分布在全球各地的Google数据中心站点,站点之间采用IP-in-IP隧道跨越IP互联网,并构建站点级的网络,通过集中控制的流量调度,实现站点之间流量均衡和链路带宽最优利用.
IP隧道技术不仅应用在数据中心企业网内,在IP基础设施的互联网中也有许多应用.
JoeTouch等人在IETF草案[16]中总结了在互联网体系结构中的IP隧道技术.
该草案总结了已有支持IP隧道的协议和面对的问题挑战,讨论了IP隧道协议设计中需要考虑的关键问题.
SimonPeter等人在[17]中提出了一种互联网上跨自治域级别的转发路径隧道,通过隧道把多个域间路径段连接起来,提供不同于BGP路由路径的额外端到端路径,可以实现域间流量绕过传统BGP路由路径,避免域间链路拥塞或者故障等问题.
LISP协议[18]用于把互联网核心网和边缘网地址空间分离,通过LISP期张克尧等:软件定义网络中基于匹配转发表的IP隧道3映射-封装隧道方式互联边缘网络,以减少核心网路由表.
AlbertoRodriguez-Natal等人[19]提出采用LISP协议作为软件定义网的一种南向接口协议,以集中控制方式管理LISP隧道映射表,以及引入重封装隧道路由器,把LISP隧道连接起来构建虚拟网络,实现网络隔离、流量工程.
上述已有工作包含了多种隧道技术和应用,但都仍然以配置方式构建隧道.
在面对大规模、异构和动态场景时仍然存在问题与挑战.
与已有工作不同,本论文提出了基于匹配转发表的隧道构建模式,以SDN可编程方式根据所需灵活动态地建立隧道,屏蔽了底层隧道不同的实现配置方式.
3系统设计3.
1总体设计SDN网络中MAT隧道的总体架构如图1所示.
数据平面包含经过扩展的支持隧道相关流表的交换机.
数据包通过匹配隧道相关的流表实现隧道相关的特性与功能,并通过动作(Action)实现隧道报文的封装与解封.
控制平面的控制器与数据平面的SDN交换机之间运行标准化的OpenFlow协议,本文扩展了OpenFlow协议Flow_Mod消息中的Match和Action字段,从而保证控制器能够向SDN交换机下发隧道相关的流表.
图1MAT隧道总体设计考虑到在SDN网络中,网络管理员常常会使用REST应用管理网络,我们也在控制器上抽象出了用于隧道功能的RESTAPI.
通过RESTAPI,用户可以更加方便地使用Python或者Shell等脚本语言实现隧道相关流表的下发与删除,从而完成隧道的建立与拆除.
以图1的情景为例,租户A使用Host1和Host4建立虚拟网络1,租户B使用Host2和Host3建立虚拟网络2.
我们为虚拟网络1和虚拟网络2分配的VNI分别为1001和1002.
网络管理员通过RestAPI请求在Switch1和Switch2两个交换机之间建立两条IP隧道,这些IP隧道以扩展的OpenFlow流表的形式下发到交换机上,并由这些流表完成隧道报文的封装和解封.
3.
2基于匹配转发表的隧道模型OpenFlow协议作为控制器平面与数据平面之间通信接口,其工作方式则基于MAT模型.
在该模型中,数据包头部域的一个子集会与一张或多张表进行掩码匹配,而每个匹配的表项中则指定了相应的动作,这些动作最终会被应用到该报文中,从而完成处理过程.
匹配转发表构成了OpenFlow中报文处理的管道(Pipeline),并有效支持了OpenFlow灵活可编程的特性.
由于匹配转发表标识了一组具有相同特征的数据包,因此在OpenFlow中也被称为流表.
但是现有OpenFlow协议中的匹配转发表却并不支持隧道报文的处理.
因此在当前的软件交换机实现中,在两个交换机之间建立IP隧道需要通过人工或者OVSDB等方式进行配置,生成一个虚拟的隧道端口,根据隧道端口类型的不同,实现不同隧道报文的封装和解封,同时隧道的控制信息和策略则保存在交换机本地.
图2MAT隧道对OpenFlow协议的扩展为了充分利用MAT模型所带来的灵活性,论文扩展了OpenFlow协议中的流表用以支持IP隧道的功能,形成了MAT隧道模型.
OpenFlow消息中使用TLV(Type,Length和Value)的形式对网络数据进行重组,能够支持对于流表结构的灵活扩展.
如图2所示,MAT隧道对于流表中MatchTLV和ActionTLV进行了扩展.
在MatchTLV中我们增加了新的Match类型去匹配隧道头部的字段,例如VxLAN隧道的VNI.
而在ActionTLV中增加了两类Action分别用于隧道报文的封装与解封,例如对于VxLAN隧道增加了PUSH_VxLAN_TUNNEL和POP_VxLAN_TUNNEL两个Action.
其中用于封装的Action中还定义了封装隧道的参数,例如src_ip、dst_ip和vni等.
当完成MatchTLV和ActionTLV的扩展后,在Flow_Mod消息中就可以指定新增的Match和Action类型,进而完成对于Flow_Mod消息的扩展.
在MAT隧道模型中,隧道的建立以流表下发的方式,而非配置的方式.
建立隧道时,MAT模型下需要在两端交换机下发总共四条流表,每个交换机上包含一条隧道报文封4计算机学报2017年装动作及一条隧道报文解封动作的流表,而不需要生成额外的虚拟端口.
交换机流表中不同的动作类型,对应不同的隧道类型.
对应于传统方式的隧道,隧道的配置信息以动作的参数体现,交换机根据匹配转发表完成隧道端点(TEP,TunnelEndpoint)的功能.
隧道的控制信息和策略通过控制器进行统一的管理,从而将隧道的控制与转发相分离.
我们在开源交换机OVS中实现了MAT隧道.
隧道报文的转发过程和处理流程在下文描述.
3.
3隧道报文的转发过程本部分将描述和对比OVS中传统配置方式隧道和MAT隧道报文的转发过程.
如图3所示,假设Host1与Host2属于不同物理网络进行通信,需要在OVS1和OVS2之间建立隧道.
在OVS中以传统配置方式建立隧道时,如图3(1),需要在OVS1和OVS2上进行配置,生成隧道端口,并将隧道端口加入到OVS网桥中.
Host1发送报文时,原始报文通过OVS网桥匹配流表并被送至隧道端口,从而被封装成相对应的隧道报文.
封装完成的数据包而后被主机网络协议栈处理,匹配路由表后从eth1端口发出.
隧道报文经过外部的IP网络最终被路由至OVS2,OVS2解封外部的MAC和IP头部,并根据隧道类型送给相应的隧道模块,隧道模块解封装隧道头之后送到OVS2的网桥,而后报文匹配网桥上的流表后最终送到Host2.
在报文传送过程中,发送端进行了两次端口转发、一次流表匹配、一次协议栈路由表匹配,在接收端进行了两次端口转发、一次流表匹配.
建立基于MAT模型的隧道只需在OVS1和OVS2上各下发两条关于隧道封装和解封的流表.
如图3(2)所示,eth1被直接加入到OVS网桥中.
Host1发送报文时,原始报文经过OVS网桥,通过匹配流表直接封装成对应的隧道报文并从eth1端口送出.
需要说明的是物理端口eth1加入OVS网桥后,IP地址就会失效,因此此处隧道报文的源IP地址和目的IP地址应由控制器分配一个可供路由的IP地址,以确保外网对于隧道两端交换机的可达性,同时为了二层的封装,控制器也需要处理此IP地址的ARP消息(详见3.
5章节).
隧道报文到达OVS2之后匹配网桥上的流表,而后对隧道报文进行解封,并从eth2端口送出,最终送达Host2.
在报文转送过程中,发送端进行了一次端口转发,一次流表匹配,在接收端进行了一次端口转发、一次流表匹配.
从发送和接收两端交换机的转发流程看,MAT隧道简化了报文转发的流程,可以减少内核协议栈的开销.
3.
4隧道报文的处理流程MAT隧道的核心功能在于隧道报文的封装与解封.
本文通过扩展OpenFlow协议,在OpenFlow协议中自定义隧道相关的匹配字段和动作完成封装和解封过程.
如图4所示,下面将对MAT隧道报文在OVS交换机内部的处理流程进行说明.
为了提高交换机的处理效率,OVS在设计时包含了用户空间和内核空间两个部分.
数据报文经过协议栈被送至OVS的内核空间,OVS首先会对报文进行解析,提取出报文的头部信息,然后根据提取出的头部信息首先查询内核态的流表.
当OVS在其内核态流表中找到了与报头匹配的表项,则根据该流表对应的动作执行.
我们在此部分扩展了新的动作具体完成隧道报文的封装和解封,不同的隧道类型对应着不同的动作.
例如对于VxLAN隧道的封装,其对应的动作由用户指定隧道两端的IP地址以及VNI等信息作为参数,隧道封装动作的执行过程会依次添加VxLAN头部、外层UDP头部、IP头部以及MAC头部.
解封过程则恰好相反.
自此,数据报文完全在内核空间处理完成并转发,这条执行路径被称为"快速路径".
由于内核态流表只是用户态流表的一个子集,因此在隧道报文首次经过OVS时并不会有内核态流表匹配,此时该报文会通过Netlink消息上交到用户空间进入"慢速路径".
用户空间同样有报文解析、流表查询的过程,而当用户态流(1)OVS实现的标准隧道报文的转发(2)基于MAT模型的隧道报文的转发图3隧道报文在OpenvSwitch中的转发过程期张克尧等:软件定义网络中基于匹配转发表的IP隧道5表查询完成时会进行动作的解析,将OpenFlow的动作转化为更为具体可以直接执行的动作.
此后,OVS一方面在用户空间中执行该动作,另一方面将匹配的用户态流表转化为内核态流表并通过Netlink消息传递给内核模块.
我们在以上用户态的处理过程中的每一部分都增加了隧道相关的模块,从而在用户态也能够支持隧道报文的匹配以及封装解封装动作.
图4隧道报文在OpenvSwitch内的处理流程当用户态也没有匹配的流表项时,OVS会向所连接的控制器发送Packet_In消息,控制器则以Flow_Mod的消息向OVS下发流表规则,OVS需要将控制器下发的流表规则进行解析并存储到自己的用户态流表中.
同样,我们在流表解析的过程中增加了对于隧道相关的匹配和动作项支持,从而保证了隧道相关的流表规则能够正确添加.
3.
5基于控制器的ARP代理在OVS的实现中,当网卡设备加入到OVS网桥后,其原有的IP地址就会失效,因此就无法再处理ARP消息,因此我们提出了基于控制器的ARP代理,从而保证MAT隧道能正确工作.
本模型中的ARP消息管理分为两类:主机的ARP消息管理以及隧道交换机的ARP消息管理.
图5表示了主机相关的ARP消息管理.
由主机发出的ARP请求报文会在其所连接的第一跳SDN交换机以Packet_In消息封装并送给控制器,控制器收到该ARP请求后,根据发送方的IP和MAC更新MAC-IP映射关系表,同时在表中查询目标IP地址对应的MAC地址.
如图5(1)所示,如果在表中找到了相应表项,则控制器直接构造ARP应答报文,其中二层帧的源MAC地址为控制器的MAC地址(或者控制器唯一标识的自身虚拟MAC地址).
控制器组建的ARP应答报文最终以Packet_Out消息的形式被送到原先的SDN交换机,最终发送方收到该响应报文.
图5(2)表示在MAC-IP表中未查询到目标IP地址的情形.
此时控制器代理发送方主机洪泛该ARP请求报文,而目标主机响应的ARP消息同样在第一跳SDN交换机上以Packet_In消息发送给控制器.
控制器根据ARP响应报文更新MAC-IP映射表.
此后则按照(1)中的过程再由控制器构造ARP响应报文并发给发送者主机.
图6表示了隧道交换机相关的ARP消息管理.
控制器会给每个隧道交换机分配一个唯一的虚拟IP地址和虚拟MAC地址,而这个映射关系也同样被记录在控制器的MAC-IP映射表中.
(1)控制器直接响应ARP请求(2)控制器代理洪泛ARP请求图5主机相关的ARP消息管理隧道交换机ARP消息管理需要考虑隧道是否跨三层网络.
如果隧道两端的SDN交换机均在同一个子网内,则不存在ARP的问题,此时隧道报文的外部源MAC地址为隧道入口交换机的虚拟MAC地址,源IP地址为该交换机的虚拟IP地址,外部目的MAC地址为隧道出口交换机的虚拟MAC地址,目的IP地址为该交换机的虚拟IP地址.
该隧道报文最终总能到达隧道出口交换机,并完成解封装.
如果隧道两端的SDN交换机跨越三层网络,则在隧道入口处,所封装的隧道报文外部目的MAC地址变为入口交换机所连接网关的MAC地址,目的IP地址变为网关的IP地址.
该隧道报文通过三层网络最终被路由至隧道出口交换机所连接的网关,此时网关会发送ARP请求,ARP请求的目标IP地址就是隧道出口交换机的虚拟IP地址,该ARP请求会在隧道出口交换机以Packet_In的消息发送给控制器,控制器收到ARP请求后,构造ARP响应报文,填充目标硬件地址为隧道出口交换机的虚拟MAC地址.
该ARP响应报文以6计算机学报2017年Packet_Out消息发送给隧道出口交换机,并从原请求的入端口送出,并由网关接收.
网关完成隧道报文外部的二层帧封装并送到隧道出口交换机,从而完成隧道报文的解封装.
本模型中基于控制器的ARP代理的主要作用有两方面.
一是利用SDN网络中控制器集中管控的优势,在绝大多数情况下避免了ARP广播报文在网络内部泛滥的情况,降低了网络的负载;二是利用控制器对于隧道交换机的虚拟IP和虚拟MAC进行管理,并处理隧道交换机相关的ARP消息,从而可以在SDN交换机数据端口没有IP地址的情况下支持三层隧道的构建.
图6隧道交换机相关的ARP消息管理3.
6MAT隧道的隔离性支持在数据中心虚拟化网络中,隧道建立的场景常常需要满足提供租户隔离性的需求.
隧道的隔离性保证了不同租户的流量无法互通.
而以NVGRE和VxLAN为代表的用于虚拟化的隧道协议都提供了隔离性支持,两个租户在三层可能使用相同的地址集合,但是他们之间并不能相互访问.
图7MAT隧道的隔离性支持在MAT模型中,同样需要支持隧道的隔离性.
如图7所示,以VxLAN隧道的隔离性为例.
首先控制器根据管理的策略给每个主机分配VNI,不同租户应具有不同VNI.
当两台主机间请求建立隧道时,控制器首先检查两台主机是否属于同一个VNI,如果不是,则直接拒绝该隧道的建立.
如果是,则控制器会在VNI-MAC-VTEPIP表中添加两条表项,分别是源主机VNI-源主机MAC-隧道入口交换机虚拟IP、目的主机VNI-目的主机MAC-隧道出口交换机虚拟IP.
而后控制器向隧道入口和出口交换机下发流表.
入口交换机上的流表匹配入端口、源MAC、目的MAC、目的IP地址,而动作则包括新增的隧道封装动作,例如PUSH_VXLAN_TUNNEL,该流表需要传入源IP地址、目的IP地址和VNI等参数.
出口交换机上的流表匹配源端口、源地址、目的地址以及VNI,动作则包括了新增的隧道解封装动作,例如POP_VXLAN_TUNNEL.
一条双向的基于MAT模型的隧道需要下发2x2条流表规则,在表1中展示了Host1->Host4方向的两条流表.
由于在Switch1和Switch2上有两个虚拟网络,因此需要建立两条隧道.
对于不同的VNI,控制器下发了不同的流表动作,由于控制器知道每个VNI对应交换机的哪些端口,因此只是将报文送到对应的端口,从而实现了不同虚拟网络之间的隔离.
表1MAT隧道中隧道端点交换机的流表规则4系统实现与实验评估MAT隧道的数据平面基于开源软件交换机OpenvSwitch2.
6.
1完成原型实现,包含了GRE和VxLAN两种IP隧道.
同时,我们还基于开源控制器Floodlight1.
2完成了控制平面的原型,并提供了RESTAPI支持.
该项目主页为:https://github.
com/mat-tunnel.
本实验拓扑采用了TopologyZoo数据集提供的中Sprint的真实拓扑[20].
该拓扑由11个节点和18条链路构成.
如图8所示,我们使用VmwareESX作为虚拟化平台搭建上述拓扑,将该拓扑中的每个节点映射为一台虚拟机,并将链路映射为虚拟机之间的连接关系.
而在每一台虚拟机中,安装带有MAT隧道功能的OVS.
此外还需要两台虚拟机作为名称MatchAction隧道入口交换机inport=fromhost1src_mac=host1MACdst_mac=host4MACpush_vxlan_tunnel=(src_ip=switch1虚拟IP地址dst_ip=switch2虚拟IP地址vni=1001)output=switch1外部端口隧道出口交换机inport=switch1外部端口src_ip=switch1虚拟IP地址dst_ip=switch2虚拟IP地址udp_port=4789(VxLAN)vni=1001pop_vxlan_tunneloutput=toHost4(属于网络1的所有端口)期张克尧等:软件定义网络中基于匹配转发表的IP隧道7通信主机,并与OVS直接相连;一台虚拟机作为控制器,与各OVS通过网络连接,以实现对各个OVS的控制和管理.
我们首先将两台通信主机接入实验拓扑中,两台相连的OVS之间建立隧道以模拟节点之间Overlay的场景.
通过控制器向对应的OVS下发流表控制两台通信主机连续经过1-5跳隧道,并使用ping工具测量每种情况下两台主机之间的通信延迟.
同时我们引入了两台OVS之间不建立隧道的情形作为对照.
图9展示了使用MAT模型的GRE、VxLAN隧道以及OVS标准实现的GRE、VxLAN隧道的平均延时(300个包)对比.
更进一步,我们对于经过5跳隧道得到的延时数据做了统计,图10展示了统计结果.
图8实验拓扑隧道的延时测试表明,基于MAT模型的隧道由于简化了数据包在OVS内部的处理流程,相比于OVS实现的标准隧道,平均延时降低了10%左右.
而延时分布表明,基于MAT模型的隧道在绝大多数数据上的分布更为集中,但标准差较大,主要源于异常值数量偏多.
这是因为在具体的原型实现中,由于隧道报文封装需要扩展头部,而当预留的头部空间不足时,就有可能会额外进行内存的拷贝,从而导致了异常值偏多的问题.
我们认为通过对于具体实现的优化可以解决这样的问题.
图9两台主机之间Ping时延测试我们还进行了通过隧道进行路径切换的实验.
两台通信主机分别接在OVS1与OVS3上.
通过断开和恢复OVS之间的链路,引起路径切换.
而两个相连OVS之间需要建立隧道,因此路径的切换最终引起隧道的建立与拆除.
例如两台通信主机原有的通信路径为:HOST1-OVS1-OVS10-OVS4-OVS3-HOST2.
当断开OVS10与OVS4之间的链路后,路径需要切换为:HOST1-OVS1-OVS10-OVS9-OVS4-OVS3-HOST2.
在这个过程中,OVS10与OVS4之间原有建立的隧道需要被拆除,而OVS10与OVS9、OVS9与OVS4之间的隧道需要被建立,而另一方面也需要通过控制器下发流表规则以新路径进行数据包转发.
对于OVS标准实现的隧道,通过OVSDB的方式下发隧道配置并额外下发用于转发的流表,而基于MAT模型的隧道则将隧道封装解封装的流表与用于转发的流表进行合并而一次性下发给相关的OVS.
图11展示了实验过程中链路与通信主机之间路径的变化情况.
图10两台主机经过5跳隧道的ping延时分布图11链路变化与通信主机之间的路径变化过程我们通过iperf工具(UDP流,指定带宽为800Mbps)测试了两台通信主机在路径变化过程中吞吐量与抖动,测试结果取三次实验的平均值,如图12、13所示.
路径切换测试表明,基于MAT的隧道模型相比于OVS实现的标准隧道,路径切换过程中的最大抖动最多可降低3个数量级,而吞吐量损失也降低了2倍.
这是因为隧道的删除和建立与用于转发的规则合并到流表中进行下发,而标准隧道需要独立的使用两套接口分别完成隧道删除建立和转发规则的下发,因此在使用隧道进行流量调度的过程中,基于MAT模型的隧道具有高效灵活的特征.
8计算机学报2017年图12路径切换过程中两台主机间的通信抖动变化图13路径切换过程中两台主机间的吞吐量变化5总结IP隧道技术在网络中具有十分广泛的应用,而在SDN网络中,现有的IP隧道存在难以维护、配置复杂和灵活性不足的问题.
本文提出了一种基于匹配转发表的隧道模型,并引入了基于控制器的ARP代理解决了该隧道模型中主机和隧道交换机对于ARP报文处理的问题,同时也在该隧道模型中考虑了隔离性的支持问题.
我们基于开源软件交换机OpenvSwitch和开源控制器Floodlight初步实现了基于匹配转发表的GRE和VxLAN隧道.
主机时延和路径切换两个方面的实验评估表明,基于匹配转发表的隧道具有更低的延时以及更小的路径切换开销.
致谢本研究获得国家"十三五"重点研发计划(No.
2017YFB0801701)和国家自然科学基金(No.
61472213)的资助.
参考文献[1]ChowdhuryNMMK,BoutabaR.
Asurveyofnetworkvirtualization.
ComputerNetworks,2010,54(5):862-876.
[2]KurianJ,SaracK.
Asurveyonthedesign,applications,andenhancementsofapplication-layeroverlaynetworks.
ACMComputingSurveys(CSUR),2010,43(1):5.
[3]LuaEK,CrowcroftJ,PiasM,etal.
Asurveyandcomparisonofpeer-to-peeroverlaynetworkschemes.
IEEECommunicationsSurveys&Tutorials,2005,7(2):72-93.
[4]AhlgrenB,DannewitzC,ImbrendaC,etal.
Asurveyofinformation-centricnetworking.
IEEECommunicationsMagazine,2012,50(7).
[5]ONFWhitePaper,Software-DefinedNetworking:TheNewNormforNetworks,OpenNetworkingFoundation,2012.
[6]McKeownN,AndersonT,BalakrishnanH,etal.
OpenFlow:enablinginnovationincampusnetworks.
ACMSIGCOMMComputerCommunicationReview,2008,38(2):69-74.
[7]PfaffB,PettitJ,KoponenT,etal.
TheDesignandImplementationofOpenvSwitch.
NSDI.
2015:117-130.
[8]PfaffB,DavieB.
TheopenvSwitchdatabasemanagementprotocol.
RFC7047,2013.
[9]MahalingamM,DuttD,DudaK,etal.
Virtualextensiblelocalareanetwork(VXLAN):Aframeworkforoverlayingvirtualizedlayer2networksoverlayer3networks.
RFC7348,2014.
[10]FarinacciD,TrainaP,HanksS,etal.
Genericroutingencapsulation(GRE).
REC1701.
1994.
[11]BariMF,BoutabaR,EstevesR,etal.
Datacenternetworkvirtualization:Asurvey.
IEEECommunicationsSurveys&Tutorials,2013,15(2):909-928.
[12]GargP,WangYS.
NVGRE:Networkvirtualizationusinggenericroutingencapsulation.
RFC7637.
2015.
[13]GrossJ,GangaI,SridharT,etal.
Geneve:Genericnetworkvirtualizationencapsulation.
IETFdraft,2017.
https://tools.
ietf.
org/html/draft-ietf-nvo3-geneve-04[14]MainoF,KreegerL.
ElzurU,etal.
,GenericProtocolExtensionforVXLAN.
IETFdraft,2017.
https://tools.
ietf.
org/html/draft-ietf-nvo3-vxlan-gpe-04[15]JainS,KumarA,MandalS,etal.
B4:Experiencewithaglobally-deployedsoftwaredefinedWAN.
ACMSIGCOMMComputerCommunicationReview,2013,43(4):3-14.
[16]TouchJ,TownsleyM,etal.
IPTunnelsintheInternetArchitecture.
IETFdraft,2017.
https://tools.
ietf.
org/html/draft-ietf-intarea-tunnels-07[17]PeterS,JavedU,ZhangQ,etal.
Onetunnelis(often)enough.
ACMSIGCOMMComputerCommunicationReview,2015,44(4):99-110.
[18]FarinacciD,LewisD,MeyerD,etal.
Thelocator/IDseparationprotocol(LISP).
RFC6830.
2013.
[19]Rodriguez-NatalA,Portoles-ComerasM,ErmaganV,etal.
LISP:asouthboundSDNprotocol.
IEEECommunicationsMagazine,2015,53(7):201-207.
[20]TheInternetTopologyZoo,http://www.
topology-zoo.
org/dataset.
html