一种面向SD-WAN的协议无感知快速源路由转发方案

李维勇,吴 阕,张 伟,陈云芳

(1.南京信息职业技术学院 计算机与软件学院,南京 210023; 2.南京邮电大学 计算机科学与技术学院,南京 210023)

0 概述

通信技术与云计算技术的发展推动了网络应用向云端的迁移,然而不同网络间的兼容需求导致互联网作为网络整体的更新速度十分缓慢,且传统广域网所承载的流量逐渐饱和甚至溢出。影响兼容性的一个主要因素是网络的数据平面与控制平面都由底层硬件厂商控制并且紧密耦合,硬件厂商通常会隐藏各自管理接口的底层细节,导致网络管理人员添加新的协议时会使其功能不灵活,网络的可编程能力羸弱。软件定义网络(Software Defined Network,SDN)[1]通过OpenFlow[2]协议解耦控制平面和数据平面,极大地提高了网络整体的运维管理、流量控制与可编程能力,因此逐渐成为下一代网络的主流设计。软件定义广域网(Software Defined-Wide Area Network,SD-WAN)[3]通过引入SDN技术来管理广域网,将网络控制能力通过软件方式进行“云化”,降低网络开支,提升网络互连能力。以Cisco为首的传统网络企业推动了开源SDN平台的发展,2013年8月,Google首次将其数据中心之间流量通信的SDN解决方案B4[4]公布,成为了市场上SDN实际部署的成功案例。然而,由于广域网的规模巨大、缺乏应用感知能力等特征,要将SDN技术部署在广域网中仍是一项重大的挑战。

在SDN实现技术中,OpenFlow是使用较为广泛的协议,用于描述控制器和交换机之间的通信接口。然而支持OpenFlow的SDN交换机中的流表数量小,难以实现细粒度的流量控制和管理,在数据平面上只能通过计数器来记录少量流信息,无法支持同一条流内不同数据包之间的信息共享。同时,由于OpenFlow在数据平面上使用了协议相关的抽象模型,其交换机的匹配字段在出厂时已被预先定义,造成交换机在数据平面上的灵活性和可编程能力不足的问题。

本文利用协议无感知转发(Protocol-Oblivious Forwarding,POF)[5]技术来解决上述问题,POF是一种基于OpenFlow协议开发的扩展技术,它具有OpenFlow协议的基本特征,即集中控制器驻留在控制平面,并且基于流表来管理数据平面中交换机的转发行为。然而不同的是,POF提出全新的OpenFlow匹配域字段和一组描述处理动作的通用指令集,在SDN交换机中实现与协议无关的快速转发[6],节省交换机的内存并减少与控制器之间的通信,省去大量的控制器决策和下发消耗时间,降低网络中的传输延迟。

1 相关工作

对于下一代广域网的探索始于2004年,DSL论坛首次提出基于用户端设备(Customer Premises Equipment,CPE)的广域网管理协议[7],该协议通过一种自动配置服务器对CPE进行自动化的配置以及策略的下发。混合广域网[8]技术通过检测不同的CPE网络对广域网进行协同、负载均衡,此外允许一些高优先级的流量通过优化后的额外线路进行传输,降低企业网络对专线的依赖。应用路由器[9]为CPE融入了应用感知功能,根据流量所属应用的优先级分配线路,保证重要流量的稳定性和安全性,这些技术结合传统的广域网加速技术构成了SD-WAN的雏形。关于SD-WAN的研究主要包括多控制器部署问题、交换机动态迁移问题和服务质量(Quality of Service,QoS)保障问题等。文献[10]最早提出控制器部署问题,在利用控制器部署时采用贪心算法,以平均时延和最大时延作为优化目标。文献[11]提出一种运用控制器位置部署算法在网络中选择合理位置进行控制器部署,使控制器以最可靠的链路到达OpenFlow交换机的设计方案。针对QoS保障问题,文献[12]针对期限驱动类型的流量,提出一种在不同WDM网络架构中的灵活速率传输方案,且把期限属性作为QoS保障问题的参数。文献[13]提出的基于空间信息网络的统一资源调配策略,提升了链路利用率与可靠性。

关于SD-WAN的新热点研究是快速路由转发问题[14],SDN集中式的网络管控使得每一条转发路径的建立都需要控制器向路径上的每个交换机逐一下发流表项,这将会导致建立路径的时间增加。基于SDN的源路由被认为是一种解决此类问题的策略[15],源路由最大的特点是所需的网络拓扑信息是由源主机提供的。在源路由中,主机根据多个不同的子网或内网地址,在数据包头部添加相关的路由信息来为数据包规划转发路径,从而实现网络中的数据平面有选择性地将数据包发往不同的目的地址。与传统的路由协议相比,源路由大幅简化了数据平面的复杂度。

目前源路由方案多数采用OpenFlow协议来实现对多标签协议互换(Multi-Protocol Label Switching,MPLS)[16]和虚拟局域网(Virtual Local Area Network,VLAN)的支持。文献[17]提出一种使用多个VLAN tag字段封装路径的SwitchReduce方案。文献[18]提出采用多个MPLS Label字段封装每一跳出口信息的方案。文献[19]利用MPLS字段进行路径信息的封装,提出一种针对数据中心虚拟化系统环境的基于端口交换的源路由方案。由于VLAN或者MPLS协议首部长度为32 bit,而表达一条路径信息需要将多层上述协议首部进行嵌套封装,因此,使用现有的协议字段进行路径信息封装会造成很大的带宽开销。为了减少源路由首部的带宽开销,文献[20]通过使用VLAN的VID字段封装出口信息来减少带宽开销,但交换机的端口数量受限(不能超过8个)。文献[21-22]提出使用以太网首部去封装路径信息来降低带宽开销的方案,但是,这种源路由首部的设计仍然不够灵活并且可能导致网络中数据包的兼容性问题。Princeton大学的研究团队在文献[23]中提出一种只执行源路由转发的交换机架构来降低交换机的成本,然而基于该架构的拓扑发现策略中,所有主机都要探测全局的网络拓扑,该策略会造成很多探测包冗余,严重影响网络的性能。文献[24]提出一种利用余数系统的转发架构来介绍交换机上流状态的存储,但在扁平控制方式中,每个控制器只能控制局部网络,造成了一定资源的浪费,且增加了网络更新时控制器的整体负载。

针对以上问题和现状,本文提出在SD-WAN中基于POF流指令集实现的、协议无关的快速源路由转发方案,采用一种源路由的交换机算法在入口交换机中压入整条转发路径,在实现转发功能的同时避免了沿途交换机与控制器的频繁交互,当数据包进入SDN环境时对其进行封装,使网络中的软件交换机可以通过特殊字段识别流量并进行转发,该方案具有节省带宽和减少流表使用的高效数据包转发特点。

2 协议无感知快速转发的源路由方案

2.1 方案整体设计

针对高流量的广域网环境,本文提出在SD-WAN中基于协议无感知快速转发方案,进一步解耦网络的控制平面和数据平面来实现与协议无关的转发行为,利用POF的高可编程性和协议无关性特征重构源路由包头字段,用于封装完整的转发路径,并利用算法实现源路由数据包的处理,以降低流表项资源的开销。

本文方案主要包括以下4个步骤:

步骤1数据包设计:在入口交换机上将流量的转发路径处理信息封装在数据包首部,在后续路径上的中间交换机中,只需要根据数据包首部存储的处理信息进行转发,避免或减少在流表中的匹配过程。

步骤2数据包处理算法设计:利用POF的可编程性,设计边界交换机与核心交换机的处理算法,路径上的中间交换机只需维护少量并且固定数量的流表项来转发网络中所有的流量,减少控制器和交换机之间的信令交互,降低流表项数量,从而进一步降低网络中流表资源的开销。

步骤3控制器网络拓扑检测:使用链路层发现协议(Link Layer Discovery Protocol,LLDP)[25]在SD-WAN环境下获取控制器的拓扑信息,实现协议无感知转发的全局拓扑检测。

步骤4无感知转发设计:基于流水线与组表相结合的协议架构,将多张串联起来的流表共同组成一条流水线,不同的流表用于实现不同的网络功能,流表定义的动作统一由POF的匹配域字段搜索关键字定位需要操作的数据来实现协议无关的快速转发。

本文方案利用SD-WAN中入口边界交换机只与控制器进行信息交互的特征,统一为后续核心交换机流表匹配新的元数据参数,不需要为不同的协议去重新向控制器请求新的流表项,从而减少转发过程中的路由决策造成的延迟。

2.2 源路由数据包设计

由于POF的协议无关性,因此不需要在传统协议中重用头字段。包头字段可以专门定制以实现有效的路由。在这种方法中,完整的转发路径会记录在这个POF中间字段中,这种解决方案的思想与MPLS类似,即POF将相关的字段插入在以太网包头和IP包头之间,具体如图1所示。

图1 源路由数据包设计

封装的包头中包括生存时间(Time-to-Live,TTL)以及控制器检查拓扑所决策出的完整转发路径上的转发端口均是按到达顺序依次排列的。TTL在进入POF网络边界时由控制器计算得出,数据分组每经过一个SDN交换机,交换芯片会根据TTL和偏移量获得当前设备的转发端口并将TTL的数值减去1,当离开POF边界时,其值正常情况应当为0,用于检测路径的合法性。假如TTL的数值提前减至0,该数据分组会被丢弃,并触发一个异步报文提交给上级控制器报告异常。

在插入新的字段后,修改以太网包头的类型字段为“0x0908”来表明以太网帧包含一个基于POF的数据分组。

2.3 源路由数据包处理

当一个流的第一个数据分组到达一个入口边界交换机时,它会根据偏移量和长度判断该数据帧的以太网类型,假如匹配POF环回口头部字段成功,其会触发一个Packet-In消息发送到SDN控制器并修改以太网帧类型字段,否则为原有的“0x0800”。由于没有流条目对应,当接收到Packet-In数据分组时,控制器为这条流计算路由路径,并发送一个Flow-mod消息到入口边界交换机,该交换机将指定的输出端口编码给路径上的每个交换机使用。入口边界交换机将输出端口存储在元数据中,并使用通用指令集将它们插入到流的每一个数据分组中。边界交换机的处理算法如下:

算法1边界交换机处理算法

输入O:offset;L:length;P:packet ID

输出output port ID

1.if O == 96b and L == 16b then

2.P.ether.type 0x0908

3.sendPacket2Controller(P)

4.else

5.P.ether.type 0x0800

6.end if

7.P.ttl MAX_VALUE

8.P.metadata.portBuffer initializeFromPacket(P)

9.return output ID(P)

当一个核心交换机接收到流交换机发来的POF数据分组时,它会利用一种预装管道式的匹配规则来进行流表匹配并进行数据分组。由于完整的转发路径已经保存在数据分组的POF中间字段之中,交换机不再需要与SDN控制器进行交互,只需要从元数据中解封装当前交换机节点的转发端口即可。核心交换机的处理算法如下:

算法2核心交换机的处理算法

输入P:packet ID

输出output port ID

1.if P.ether.type == 0x0908 then

2.P.metadata.portBuffer wirteMetadataFromPacket(P.port)

3.if P.ttl > 1 then

4.deleteField(P.port)

5.P.ttl P.ttl-1

6.else

7.deleteField(P.POFHeader)

8.P.ether.type 0x0800

9.end if

10.return output(P.metadata.portBuffer)

11.else

12.ddField(P.POFHeader)

13.return output ID (P)

14.end if

从上面的处理流程可以看出,在基于POF的SD-WAN中通常只有入口边界交换机需要与控制器进行信息交互,而且受益于通用指令集的网络抽象,后续的所有核心交换机在转发路径没有发生异常的情况下,只会根据新的元数据参数进行统一的通用关键字流表匹配,而不需要为不同的协议去重新向控制器请求新的流表项。这种做法大大减少了链路上的核心交换机发起的异步OpenFlow报文的情况,因此可以很大程度上减少转发过程中的路由决策造成的延迟。

2.4 全局拓扑链路获取

SDN控制器在初始化状态下会触发链路发现事件,由于LLDP协议中的目的MAC地址是一个组播地址,控制器会通过Packet-Out消息封装这条数据报文并向所有端口转发。交换机一旦接收到来自控制器的LLDP报文,就会向所有端口转发该报文,当其他交换机接收到该消息时会触发本地流表查找操作。由于交换机中不存在关于LLDP数据报文的流表,接收到这条报文的交换机又会通过Packet-In消息封装这条报文并返回给控制器,而控制器会通过Packet-Out和Packet-In中的相同信息确定2台交换机接收和发送的报文属于同一事件,且会创建一条2台交换机之间的链路记录并保存于本地。这个过程在整个网络中进行,控制器会通过这些信息获得整个网络的拓扑状态,此时网络达到收敛状态,当一条流发送到SDN环境时,控制器就能通过本地保存的拓扑信息决策出最优的转发路径。

由于真实的环境中需要在现有的网络环境下部署SD-WAN,因此这种方案具有对于传统网络设备和环境的兼容性要求。控制器除了发送封装LLDP的Packet-Out消息,还会同时发送一条控制信令使接收到该报文的交换机向所有端口发出一条广播包,假如到达一个非SDN环境的传统交换机,它会穿过该设备继续进行全端口广播,当另一端与该传统环境的交换机相连的SDN交换机接收到这个广播包时,由于缺少处理广播包的流表项,其同样会触发一个Packet-In消息提交给上级控制器,因此控制器可以确定2台交换机的链路之间存在非SDN环境,假如控制器没有收到,则会默认所有设备都运行在SDN环境下。

全局拓扑检测还有一项工作是随时更新SDN交换机链路状态以及各种逻辑组网链路状态[26]。企业的数据中心作为SD-WAN最主要的部署环境,通常具有云计算、虚拟化等需求,此时要求系统中的网络资源整体虚拟化并通过资源池进行管理,不同的租户会根据具体需求请求相关的设备、端口以及相应的带宽。这种逻辑组网具有一定的弹性,与物理组网不同,不同的租户之间的性能、安全等属性需要彼此隔离,因此,需要SDN控制器在支持逻辑组网拓扑检测的同时提供访问控制列表、QoS等高级特性支持,同时实时保存各种逻辑组网的拓扑信息、策略信息以及网络资源调度信息。

2.5 多级流表的无感知转发

在SD-WAN中,POF将多张串联起来的流表共同组成一条流水线,数据分组从被交换机接收到查询到相应的接口转发需要在多张流表之间跳转来完成匹配。不同的流表用于实现不同的网络功能,比如对于2层转发,控制器首先会进行拓扑检测并同步记录各台设备的MAC地址;对于3层转发,控制器会根据开销计算出最优的转发策略下发给交换机流表;对于4层转发,控制器不仅会匹配MAC地址与IP地址,另外还会根据TCP/UDP端口号进行匹配,并写入相应的流表项中进行下发。

POF交换机采用了一系列通用密钥组合和表查找指令来完成数据分组的解析和流的匹配。POF的匹配域字段搜索关键字是由偏移量和长度组成的二维元组。流表定义的动作(这些动作定义在POF指令集中,可以实现修改数据分组、更新POF计数器、跳转到指定流表等功能)统一通过上述二维元组来定位需要操作的数据,这种方案可以极大地加快流表决策的过程,为提供与协议无关的快速转发打下基础。

当封装了POF中间帧的数据分组上传到POF控制器时,控制器会从Packet-In消息中抽取出需要的流表统计信息以及端口统计信息,并对特定的地址分配机制(Address Assignment Mechanism,AAM)数据包进行侦听[27],构建相应的IP地址与端口的绑定表。此外,POF控制器通过主动探测发现的方式,确认封装了POF的数据分组所对应的流的入口交换机的信息,并根据POF的协议无关快速转发机制为匹配特征的流指定对应的流表项。

控制器端根据收集的数据和预处理分析提取的流特征进行IP地址与端口绑定之后,相关流的转发操作会进入相对稳定的阶段。此时,POF控制器会发送轮巡消息给与之直接相连的交换机来验证流的匹配与转发操作是否正常,而这种跟踪机制不会改变数据平面的转发行为。为了防止链路中同时存在多条轮巡相关的Packet-Out消息,POF控制器为轮巡消息引入一个随机的抖动,这使得轮巡消息的频率一致,以确保消息分时到达链路上与控制器直接邻接的不同交换机。首先,在轮巡消息到达交换机端之后会触发统计事件,收集上一个时间窗口的交换机统计信息。然后,根据这些数据信息分析验证流的转发事件以及交换机的状态变化信息。最后,根据交换机的统计信息确定是否发送异常消息以及确定新的轮巡频率,同时调整动态的端口状态。这种不断轮巡以及动态划分端口的机制可以有效满足SD-WAN中的逻辑组网需求以及QoS等高级特性,提高网络的灵活性和可扩展性。

3 协议无感知快速转发源路由系统的实现

3.1 系统模拟环境的搭建

本文选用Mininet[28]实验平台作为POF的实验环境。该系统由虚拟的终端节点和支持OpenFlow的交换机以及控制器组成,并且提供了良好的远程控制器支持。实验平台数据平面交换机是依赖于支持OpenFlow的Open vSwitch开源交换机[29],它在数据平面所对应的功能是为已经决策过的流进行后续的数据分组的核心转发模块调用和处理。在网络控制平面使用OpenDaylight控制器,该控制器具有开放服务网关独立(Open Service Gateway Initiative,OSGI)结构[30],这种结构能够隔离众多底层网络功能,因此可以很大程度上增强控制平面的可扩展性。OpenDaylight控制器的另一重大特征是存在服务抽象层(Service Abstraction Layer,SAL)[31],使得控制器可以适配SD-WAN环境中可能出现的几乎所有不同底层协议的设备,保证研究人员能够专注于SD-WAN规模的网络业务应用开发而无需关注并行的传统网络与SD-WAN的兼容问题,具体的系统实验环境如表1所示。

表1 系统实验环境

3.2 协议无感知转发部署

3.2.1 POF控制器部署

基于OpenDaylight控制器的SD-WAN网络是一个可以从逻辑上描述数据分组转发甚至计算出延迟区间、流表项量级等信息的白盒系统。在OpenDaylight控制器中添加POF扩展,使控制器可以自由使用数据分组的元数据来临时缓存转发过程中所需的数据。带有图形界面的POF模块提供接口完成手动配置转发管道,配置文件也可以通过相同的接口加载到控制器中,同时,可以使用API为POF管理器开发其他应用程序,这使得SD-WAN网元可以保持相当多的软件定义特性。图2展示了POF控制器的框架。

图2 POF控制器框架

在SD-WAN网络环境中,网络通常会由不同的运营商进行管理和运营,因此需要处理域间流量组成的流。但基于POF的域间操作的机制和实现还未得到解决,为了弥补丢失的性能,本文系统在POF控制器中还设计了一个域间模块。该模块通过JSON(JavaScript Object Notation)实现并帮助POF控制器交换域间信息。在该设计中,让每台控制器都将自己管理的自治系统(Autonomous System,AS)抽象成一台大的交换机,并生成一张域转发表来描述AS与其邻居之间的连接。当拓扑发生变化时,域转发表将广播至邻居域中的协同控制器。从所有邻居域中的协同控制器收集到域转发表后,每个POF控制器会构建一个全局虚拟拓扑并保存于本地。当域间流量到达时,其可以通过域转发表数据库计算出正确的下一个域并根据域内的拓扑信息再计算出最优路径完成转发。对于需要特定QoS的流量,控制器还可以通过与其他控制器协作,在多个域间缓存端到端的路由路径。

在域间模块之间捕获的JSON数据分组,主要用于交换域间转发表和发送端到端路径的域间消息。在该协议的数据报文中有必选字段和可选字段,POF控制器可以根据必选的类型字段判断域间数据分组需要更新的数据库。通告域间转发表的数据报文会有一个可选字段,内容是一个数组,该域内的每个出口交换机都是一个成员对象,收到这类报文的控制器可以根据这个数组知道邻居域的全局拓扑信息。通告端对端路径的数据报文则有一个匹配列表字段,成员对象是发送端和接收端的POF中间帧二维元组信息以及IP地址,当端到端的流到达该域时,控制器会优先匹配这条报文所映射的路由,这种状态直至拓扑发生变化时,控制器收到新的域间转发表才会发生增量更新。

3.2.2 POF交换机部署

为了使用POF来支持未来开发的新协议,需要在数据平面的POF交换机中预先安装相关的POF流指令集。POF流指令集的类别如表2所示。

表2 POF流指令集的类别

编辑指令用于编辑数据分组。本文系统在以太包头和IP包头之间插入POF中间帧,当IPv4数据分组进入基于POF的SD-WAN环境的入口网关时,交换机可以通过ADD_FIELD为流添加POF中间帧来区分流量,特别的是,SD-WAN中的企业网内部通常是一个采用网络地址转换协议的局域网,局域网内的数据分组传输并不会通告到其他网络中,因此即使某些值在其他网络中代表别的含义也不会发生冲突。

转发指令用于分组转发。在一个网元中,数据分组的转发过程可能会包含多个进程,用户可以根据功能将它们分成若干个流表,例如3层解析流表、3层封装流表等。

条目指令用于实现交换机对流条目进行操作,类似于EDITING指令集。对流条目进行操作可以帮助POF交换机实现许多需要学习网络信息的协议规则,例如拓扑检测、路由计算和维护邻居关系。基于POF的SD-WAN转发方案中,MAC地址与端口号的映射关系由一张单独的流表储存,它会在输入端口处检查流的MAC地址字段。如果映射表中不存在此MAC地址,用户则可以通过ADD_TABLE_ENTRY方法来添加关于源的MAC地址和输入端口,拓扑检测和路由学习也可以采用类似操作来实现。

跳转指令集帮助交换机改变数据分组的处理过程,流指令集以流的级别实现一些关于流全局状态的操作。

4 实验分析

4.1 单链路中的实验分析

单链路结构指2台终端之间只有一条链路而没有冗余,这种结构通常出现在拓扑的末端,即接入层。因为企业组网通常只需要在汇聚层为汇总的流量部署主备链路而不用为每一台终端设备都准备冗余。因此,接入层的终端之间互相通信的场景通常可以简化为这种拓扑环境下的数据分组转发。

使用Mininet自带的图形界面工具搭建的测试平台由4台基于Open vSwitch的软件交换机组成,添加了支持POF的扩展并提高了转发性能。由于需要实验验证的网络规模属于中小规模并且由个人电脑进行模拟,因此将Open vSwitch交换机在VMware虚拟机中运行。每台POF交换机都配备了2个1GbE的虚拟端口并实现基于POF的高吞吐量数据分组正常转发。

除了4台交换机外,拓扑中还有1台控制器负责控制层面决策,2台终端(h1,h2)用来模拟SD-WAN中的流量。为了验证POF的功能,使用h1对h2进行ping操作,当ICMP_Request流的第一个数据分组到达节点1时,入口交换机发现没有要匹配的流条目。随后,节点1会利用Packet-In消息封装该分组并上传到SD-WAN控制器。该控制器计算出唯一路径(1,2,3,4)并通过Packet-Out指示节点1上的交换机将POF包头插入到数据分组中以携带路径信息。需要注意的是,这些操作发生在交换机上而非控制器端,控制器通过POF流指令集完成流表下发并指导交换机完成POF中间帧的插入。插入之后的报文格式如表3所示。

表3 单链路拓扑实验中的POF封装包

节点1会把类型值改为“0x0908”来表示该数据包是一个POF封装的数据包。TTL和4个出向端口组成POF中间帧,其中TTL占8个比特用来显示该数据包的TTL,在经过每个节点时会通过DEC_FIELD指令自减1,当它到达节点4时会降为1,同时交换机会把以太类型字段修改回原来的“0x8000”。因为实际的网络中数据分组所需经过的交换机数是未知的,所以POF中间帧采用TLV可变长格式,逆序的保存了转发路径上的每一跳的出向端口,每经过一个节点交换机都会通过DEL_FIELD指令以及端口字段的标准offset和length来取出并删除最后一个出向端口,并通过OUTPUT指令完成转发。同时,由于实际网络中通常存在传统网络与SD-WAN网络并存的情况,因此上述过程可以在数据包到达节点4时还原为最初进入SD-WAN环境的格式,即使节点4到h2之间还存在一段传统网络,数据包也可以正常转发而不会因为格式变化而被误读和丢弃。

图3显示了WireShark在节点1捕获到的数据分组。其中第1个和第4个是在交换机的左侧端口捕获,其余2个则是在右侧端口捕获。可以看出,第1个数据分组是从左侧端口进入的98 Byte的ICMP_Request数据包;第2个数据分组的长度变为104字节,这正好是一个TTL字段和4个出向端口字段的长度,此外,以太帧中的类型字段也变成了“unknown(0x0908)”,可见原始数据包已经在POF控制器的指导下被封装成了适用于POF传输的数据分组;第3个数据分组是来自s2的回包,由h2发出并且长度为100 Byte即只剩下多出的TTL字段,这验证了POF中间帧在传输过程中会完成自减;第4个数据分组是长度为98 Byte的ICMP_Reply数据包,验证了封装了POF的报文在从SD-WAN的环境内转发完成之后变回了标准的原始格式。

图3 POF功能抓包验证

为了验证基于POF的SD-WAN转发方案与OpenFlow方案的性能差别,利用网络测试工具iPerf来模拟网络中的背景流量,接着进行连通性测试来记录每次实验ICMP请求到响应所产生的延迟,然后逐渐添加拓扑中的交换机数量并观察延迟的变化。图4(a)显示了OpenFlow方案与POF方案的延迟结果对比,由此可见,OpenFlow方案随着交换机数量的增多延迟显著提高,而本文提出的基于POF的转发方案可以维持一个常数级的延迟时间。这是因为基于POF的方案在数据分组到达入口交换机时就对它进行了封装,后续的交换机不需要与控制器进行信息交互而只需从POF中间帧中取出相应的出向端口就可以正确的完成转发。接着使用iPerf开始泛洪ICMP流量,用来模拟POF在真实环境中流量负荷逐渐增多的情况并持续10 s左右,观察流表条目数的变化情况,结果如图4(b)所示。由此可见,与OpenFlow方案相比,POF方案总的流表条目数大约减少了55%～67%,更重要的是随着流表条目数的增加,本文提出的基于POF的转发方案的优势越来越明显。这是因为入口交换机需要安装基于每个流的流条目,而核心交换机可以共享流条目,且传统的OpenFlow需要在转发路径的每一跳交换机上都安装基于每个流的流条目才能使数据分组正确转发。

4.2 多播POF的实验分析

除了单链路的拓扑模型,广域网中绝大多数的节点之间都存在一条以上的链路以实现负载均衡和灾难恢复。多播是当今广域网中广泛使用的通信方案,常用来实现视频会议、数据备份等服务且具有很高的传输效率。

使用POF源路由实现多播的核心问题在于如何在包头中编码整个多播树,为了解决该问题,本文设计了基于POF多播的递归方法。在获得多播树后,首先寻找其主要路径[32](指多播树最短的分支(就跳数而言),主要路径连接了源交换机与其中一台多播目的交换机),假如树存在多个最短的分支路径就随机选择其中一个。然后,在主要路径上再将分支节点[33](指从根向叶子节点路径上有多条分支链路的交换机)视为源交换机并开始查找下一级的主要路径,递归地重复这个过程直至所有目的交换机都与主要路径相连。此时,将多播树分割成若干个非重叠的分支并用其来实现基于POF的多播。为了实现POF中间帧的封装,方案依旧采用表3的结构来编码多播树,不同的是设计一个MPort字段来替换表3中的Port字段,该字段由分支节点校验位和组标签2个子字段组成。其中,分支节点校验位表示该交换机是否为分支节点,若是,则取1,否则取0。组标签字段为每个活动的多播会话分配一个标签,因此该字段可以用于在分支节点识别数据分组的多播操作,这会把数据分组水平分割到其他出向端口并在必要时在其上编码新的POF包头。当数据分组到达分支节点时,交换机会将数据分组复制为若干个副本并分别为其封装新的POF包头,当它们转发到下一跳节点时,交换机就可以根据新的POF包头对其进行正确的转发。

方案设计了基于POF的组播功能并进行性能分析。同样利用iPerf来模拟背景流量,利用iPerf在h1泛洪ICMP报文并逐渐增加泛洪规模进行压力测试,观察ICMP报文的延迟时间并比较2个方案的结果。

由于分支节点交换机会为数据分组封装新的POF包头,而非分支节点交换机遵循的转发逻辑与上一节相同,多播实验中同样也只有入口交换机即节点1需要与控制器进行信息交互,因此多播实验中的延迟和单链路拓扑中的单播场景是一致的,实验结果如图5(a)所示。由于该实验中没有增加交换机的数量,因此整个网络对于每个流的流表条目数一般是恒定的。在h2、h3、h4、h5 4台主机上记录随着流量负荷增长成功接收到的吞吐量所占百分比,即用接收吞吐量来代替流表条目数评估该方案的性能。利用iPerf在h1上生成100个多播会话并广播到4台目的主机上,每个目的地提供0.25 Mb/s的ICMP流量。对4台主机上的接收吞吐量取平均值,实验结果如图5(b)所示。其中,基于POF的多播方案可以实现接近100%的接收吞吐量。这是因为POF方案中核心交换机可以共享流条目的特性,每台交换机只存在少于1 000条的流条目数,而OpenFlow方案需要在转发路径上的每一跳上安装基于每个流的流条目才能实现正确转发。可以看到,直到每台交换机分配超过2 200个流条目时,OpenFlow方案的接收吞吐量才能接近100%。实验结果表明,对于流级别的流量管理,POF方案比传统OpenFlow方案更有效地利用流条目,这一结论不仅适用于单播场景,而且也适用于多播场景。

图5 OpenFlow方案与POF方案的多播实验结果对比

5 结束语

本文从SDN技术在广域网中的应用即SD-WAN的解决方案入手,提出一种将POF技术应用在SD-WAN环境下的源路由快速转发方案。通过理论阐释和实验验证2个方面证明该方案比原生OpenFlow方案具有更小的延迟以及更强的网络性能,这对类似政企专业类延时敏感业务具有良好的应用价值。下一步的研究工作将完善POF包头中间帧的扩展性设计,以应对更高级的应用需求,同时,基于POF的转发方案对于某些恶意流量的识别和区分也同样是值得继续深入研究的重点。