丁万夫,须成忠,古 亮
1(中国科学院 深圳先进技术研究院,广东 深圳 518000)2(深信服科技股份有限公司,广东 深圳 518000)
网络报文在传输过程中,只有依次按序经过定制的业务功能,才能确保网络可以按照设计的要求,为用户提供更加安全、可用的网络服务[1].业务链中的业务节点通常包括防火墙、入侵检测、负载均衡等等[2,3].因此,如何保证网络流量按照业务逻辑所要求的既定顺序穿过这些业务节点,以实现所需要的安全业务,已成为学术界和工业界的研究热点.
业务链在企业场景和运营商场景下有大量的应用诉求,其中应用较多的两大场景是:
1)云计算数据中心场景[4].业务链功能可以为数据中心的租户提供多种网络功能的业务链编排.云计算数据中心的主要特点是多个租户共存,每个租户对业务链编排的需求差异很大,因此业务链需具有易扩展及灵活部署的特点.
2)Gi-LAN场景[5].随着网络数据流量的显著增长,运营商在Gi-LAN场景下需要应对网络流量的激增压力以及用户的个性化需求,网络业务链不仅需要具有弹性伸缩的特点,还需要针对用户的网络流量进行更加精细化的流量管控.
传统业务链部署通常采用专用的硬件设备,基于物理拓扑,通过手工配置路由策略,将安全设备部署到业务流量路径当中,这种部署模式存在高成本支出和高运维费用等一系列亟待解决的问题[6].软件定义网络(SDN,Software Defined Network)[7,8]的概念由斯坦福大学提出.其核心思想是将转发设备的数据平面和控制平面进行分离,并让控制逻辑以软件方式运行于逻辑上独立的控制环境.SDN的本质是逻辑集中控制面的可编程化[9,10].网络功能虚拟化(NFV,Network Function Virtualization)[11]的概念由电信运营商提出.其核心思想是通过使用通用性的硬件平台以及虚拟化平台运行网络虚拟化单元,从而大幅降低网络设备的成本.NFV的本质是实现新业务的快速开发和部署[12].
本文面向SDN和NFV的融合机制,首先提出了一种基于标准化架构MANO[13]的业务链平台,然后分别对控制平面和数据转发平面的关键技术进行研究,解决了业务链平台的可靠性和可扩展性等问题.
当前网络中使用的各种设备,均是基于私有平台部署的,各种专有设备之间的硬件平台无法复用,而设备扩容需要采购硬件,且缩容后又存在硬件平台闲置的问题[14].在NFV理念下,所有硬件设备转变为应用程序,能够部署在基于x86标准的物理服务器上,通过将软硬件进行解耦,所有应用均能够实现快速的扩缩容的功能,进而显著提升部署弹性.NFV虽然有诸多好处,但其会带来跨厂商的协同和互通问题,进而提高运维成本[15].为此,欧洲电信标准协会ETSI成立了网络功能虚拟化管理和编排(NFV MANO)标准组,致力于降低NFV推广后带来的维护复杂性.如图1所示,MANO系统架构由三部分组成,从下至上分别为VIM(Virtual Infrastructure Management)、VNF-M(VNF-Manager)以及NFV-O(NFV-Orchestrator),分别完成NFVI的资源管理、VNF的管理以及网络服务与资源的编排.其中,VIM与网络功能虚拟化基础设置(NFVI)交互,VMF-M与单元管理系统(EMS)和虚拟网络功能(VNF)交互,NFV-O与运营支撑系统(OSS)和业务支撑系统(BSS)交互.基于这样的编排流程,任何一个业务网络均可以通过MANO自顶向下进行分解.
图1 NFV MANO系统架构图Fig.1 NFV MANO system architecture
虽然目前业界对业务链平台的架构没有统一,但是总的来看业务链系统架构通常包括三个层次,分别是编排层,控制层以及数据层[16,17].最上层为编排层,通常由不同功能的组件构成,可通过Restful API的方式与对应的控制层进行交互,用户可以通过可拖拽的方式对业务进行不同的组合形成统一的业务.中间为控制层,负责对网络转发设备进行统一的管理和控制,同时维护一致的网络拓扑.最底层的转发层主要包括三部分,分别是流分类器,网络转发设备以及业务功能组件.在典型的SDN系统架构的基础上,学术界设计了多种业务链控制面架构.总体来说,可以分为两类.
1)单控制器架构.如图2所示,OpenNF[18]在SIGCOMM′2014提出了一种全局统一的控制面架构,在OpenNF控制器内集成了流规则管理器和网络状态管理器,分别用于管理网络转发状态和网络功能状态.
图2 OpenNF系统架构图Fig.2 OpenNF system architecture
2)双控制器架构.如图3所示,Stratos[19]提出了一种双控制器架构,其中转发控制器用于管理和控制转发设备,而业务功能控制器用于监视和控制中间件设备,二者由租户业务链模块进行统一调度.
图3 Stratos系统架构图Fig.3 Stratos system architecture
业务链数据平面转发技术的演进过程如图4所示.传统业务链数据面转发技术通常采用策略路由(PBR,Policy-Based Routing)方案[20],PBR方案提供了一种比基于目的地址进行路由转发更加灵活的数据包路由转发机制,可以根据IP报文源地址、目的地址、端口等内容进行路由选择.PBR方案主要存在4个方面问题:
1)灵活性问题.匹配域类型相对固定且有限,导致灵活性较差.
2)可扩展性问题.不具有微流汇聚能力,导致表项增多.
3)可靠性问题.PBR表项需要静态配置,导致拓扑依赖且不支持部署自动化.
4)性能问题.PBR属于分布式DPI方案,每一跳均需与策略路由表项进行匹配,影响转发性能.
图4 业务链数据平面转发技术的演进过程Fig.4 Evolution process of service chain forwarding technology
为解决传统业务链存在的问题,产业界和学术界开始尝试通过SDN架构带来的可编程性来解决PBR方案存在的问题.流转发规则方案基于SDN架构[21,22],通过使用OpenFlow协议[23],能够自动生成转发规则,解决了PBR存在的拓扑依赖和灵活性问题,但无法解决可扩展性和性能问题.之后业界开始探索引入业务链ID方案[24],通过部署流分类器为流量打上相应的业务链ID标签,进而实现了转发过程中不再依赖具体匹配域,而是依据ID字段进行转发,能够更好地解决PBR方案和流转发规则方案存在的问题.
本文设计并实现了面向SDN和NFV融合机制的标准化业务链平台,接下来将介绍平台的系统架构以及架构所实现的核心关键技术.
业务链平台的系统架构如图5所示,核心功能组件主要包括业务链编排器、策略控制器、SDN控制器、NFV控制器以及流分类器等.编排器可以将用户自定义服务所需的资源和配置发给相应的控制器,编排器由业务链定义、业务链配置以及拓扑管理等模块组成.策略控制器负责根据用户的需求选择业务链策略,同时将网络流量的转发策略传给流分类器.SDN控制器主要对网络转发单元进行管理和控制,以及路径计算、下发流表项等功能.NFV控制器负责对VNF进行功能管理以及资源配置.流分类器负责基于策略控制器的策略,对进入网络业务流量进行分类及标识.数据转发面主要负责对网络业务流量进行转发,是由SDN交换机构建的网络.VNF是各种功能的中间件,负责对业务流进行相应的处理.
图5 标准化业务链平台系统架构图Fig.5 General framework of standardized service chain platform
3.2.1 基于多控制器的控制平面
从图6可以看出,整个业务链架构自顶向下包括3层,分别是管理面、控制面和数据面.本节重点介绍控制平面.单控制器和双控制器均存在可靠性问题,因此本文采用了多控制器的控制平面.控制平面由3个控制器组成,分别是策略控制器、SDN控制器以及NFV控制器.其中,策略控制器负责根据业务链ID的策略生成相应流表至流分类器,主要模块包括业务链策略控制以及业务链ID分配,SDN控制器负责根据网络拓扑生成相应流表至转发单元,主要模块包括拓扑管理以及流表管理,NFV控制器负责根据对VNF进行全生命周期管理,主要模块包括VNF管理器以及NVF拓扑管理.
图6 标准化业务链平台分层架构图Fig.6 Hierarchical framework of standardized service chain platform
3.2.2 基于业务链ID的转发平面
传统业务链转发方式采用的是基于策略路由PRR的方案,由于PBR存在灵活性和可靠性等问题,业界主流方案采用基于业务链ID的方案[25].如图7所示,目前基于业务链ID的转发技术可以分为3类:
1)基于已有标签字段的方案,如VLAN/VXLAN/MPLS字段.
2)基于数据报文已有字段的方案,如三层的TOS字段以及四层的TCP Option字段.
3)基于新增报文头的方案,即IETF SFC工作组建议使用专用的网络业务包头(NSH,Network Service Header)[26].NSH格式中包含了24位的业务路径(SPI),控制器将SPI作为匹配参数下发给网络转发设备完成转发.
图7 业务链ID方案分类Fig.7 Classification of service chain ID solutions
本文提出一种基于源MAC的业务链ID方案,即通过报文的源MAC字段承载业务链ID.如表1所示,我们对各类型的业务链ID方案进行了比较.其中,标签字段与原业务有冲突,L3和L4等报文字段不满足长度需求,存在可扩展性的问题,新增字段需要修改交换机和中间件,所以只有源MAC方案满足无需修改交换机、满足长度需求、与原业务无冲突以及无需修改中间件等四方面要求.此外,我们通过记录源MAC与业务链ID的对应关系,在报文出业务链时将业务链ID替换为对应的源MAC,从而使得报文在进出业务链前后的报文头信息保持不变.
表1 业务链ID方案优缺点比较
Table 1 Comparison of service chain ID solutions
匹配域需求标签字段MPLSVLANL2L3L4Src-MACToS(DS)IPv4/v6OptionTCPoption新增字段NSH是否无需修改交换机YESYESYESYESYESYESNO是否满足长度的需求YESNOYESNONONOYES是否与原业务无冲突NONOYESNONONOYES是否无需修改中间件NOYESYESYESYESYESNO
业务链平台作为企业网络和运营商网络部署的重要应用,重要性不言而喻.因此,经过架构设计和系统编码后,需要对业务链平台进行全面的系统测试,确保平台功能的准确性和完备性.为了验证本文所提出的标准化业务链平台的可行性,我们按照图8拓扑进行了平台功能测试和性能测试.测试在商用服务器(CPU为Intel(R)Xeon(R)D1528,主频为1.9GHz,内存为32G),使用千兆网卡Intel 82575进行.
图8 业务链平台测试拓扑Fig.8 Test topology of service chain platform
功能测试:用户通过拖拽方式可以新建两种业务,其中业务1的业务链编号为0001,业务2的业务链编号为0002.新建的两条业务链通过控制层将流表项下发至转发面,主机H1和H2分别对应业务1和业务2,SDN流分类器和SDN交换机的表项如图所示.我们在H1和H2上运行Iperf客户端,负责发送报文,而在H3上运行Iperf服务端,负责接收报文.控制器采用开源的OpenDayLight[26],流分类器和SDN交换机运行开源的OVS,版本号均为2.5.0,支持最新版本的OpenFlow协议.由于OpenFlow协议支持SET-FIELD动作,因此能够直接将源MAC字段修改为业务链ID字段使用.防火墙和网络地址转换通过开源的ClickOS[27]实现.我们使用Iperf工具进行了小包测试,通过Iperf客户端发送64字节的报文,在Iperf服务端能够成功接收到Iperf客户端发送的报文且无丢包,因此测试结果表明,标准化业务链平台功能正常.
图9 性能测试效果对比图Fig.9 Comparison of performance test results
性能测试:为了保证性能测试的准确性,我们采用思博伦测试仪进行发包测试.接收端接收报文后进行统计,如果不丢包则增大流量,直到出现丢包现象后,则回溯到不丢包的临界值,以此测试最大传输速率,测试包长为64字节、128字节、256字节、512字节、1518字节5种长度.图9比较了业务链ID方案与传统PBR方案的传输速率和时延,结果表明, 两种方案的传输速率和时延随着报文大小的增大均呈现上升趋势,且相较于PBR方案,基于源MAC的业务链ID方案在报文传输速率方面增长幅度在15%~20%,报文传输时延降低幅度在20%~25%.
在新的网络架构下,如何利用新的技术将创新业务更好的融合进来,从而提供便捷、安全的网络架构,是业界的研究重点.为此,提出了面向SDN和NFV融合机制的标准化业务链平台,以应对新形式下基于业务链的新需求.本文通过对传统业务链平台进行深入分析,明确了当前网络业务链平台所存在的主要问题以及标准化业务链平台对SDN和NFV两大技术的诉求.然后遵循NFV MANO标准架构设计了面向SDN和NFV融合机制的标准化业务链平台的系统架构,并在此基础上,设计实现了关键的核心技术.基于标准业务链平台,遵循多控制器机制设计一种高可靠性架构,为底层数据转发提供平台支撑,以提高业务链控制平面的可靠性,同时研究了业务链数据面转发方案,分析比较业务链转发方案的优劣,进而创新性提出一种基于源MAC的业务链ID方案,以提高业务链数据平台的可扩展性.最后对该业务链平台进行了可行性验证,测试结果表明,标准化业务链平台功能正常.