服务功能在部署时, 功能与专属硬件紧密耦合, 每个功能都嵌入在特定的硬件设备中, 导致运营成本不断提高, 网络灵活性变差, 服务部署十分困难^[1]. 为此, IETF提出一种服务功能链(Service Function Chain, SFC)架构来解决服务功能在部署过程中拓扑独立性和配置复杂性等问题^[2]. NSH以一种报头的格式被添加到网络流量中, 用于支持服务功能链架构的实现^[3].

当前, 利用软件定义网络^[4](Software Defined Network, SDN)和网络功能虚拟化(Network Function Virtualization, NFV)技术实现服务功能链已经成为了研究热点. SDN和NFV技术高度互补, 彼此互利但并不相互依赖. SDN被视为一种全新的网络技术, 通过分离网络设备的控制平面与数据平面, 将网络能力抽象为应用程序接口提供给应用层, 从而构建开放可编程的网络环境, 在对底层各种网络资源虚拟化的基础上, 实现对网络的集中控制和管理. NFV利用IT虚拟化技术定义网络功能, 通过通用硬件以及虚拟化技术, 来承载相关网络功能, 从而降低网络成本并提升业务开发部署能力, 将硬件和软件解耦, 使网络功能不再依赖于专用硬件.

到目前为止, SFC已经在多个平台上实现, 包括OpenDaylight (ODL)^[5], ONOS^[6]和OpenStack Networking^[7]. 其中, 只有ODL 平台完全采用IETF SFC架构, 包括所有核心组件、NSH协议等. ODL平台通过对OpenFlow协议的私有扩展实现了NSH协议, 然而, 这种实现方式造成了OpenFlow的兼容性问题. 由于ODL平台中OpenVSwitch(OVS)交换机^[8]通过OpenFlow协议与控制器通信, 因此, OVS交换机需要修改自身代码以实现NSH协议, 实现过程复杂. OVS交换机首先对L2或L3层的数据包添加NSH, 然后利用现有封装协议, 如MPLS、VXLAN/VXLAN-GPE在L3或L4层对数据包再次封装. 利用现有协议封装、转发NSH报文, 增加了不必要的报文处理过程, 导致网络传输效率降低.

POF协议是对SDN南向接口协议OpenFlow的扩展, 其提供了SDN控制器直接指定规则匹配字段和指令操作字段的偏移量和长度的能力, 定义了字段修改、插入、删除等指令集用于对报文进行各种操作, 从而实现了数据平面的深度可编程, 更加有效地支持新协议的实现.

本文根据IETF提出的有关服务功能链的标准, 提出了一种基于协议无感知转发的服务功能链, 该服务功能链主要是基于SDN和NFV技术, 基于Floodlight开源控制器, 利用POF协议数据平面深度可编程的能力, 提供了对NSH协议的支持, 从而构建了服务功能链. 实验结果表明, 该架构有效地实现了服务功能的部署.

本文其余小节组织如下: 第1节介绍服务功能链的相关背景; 第2节提出基于SDN和NFV技术的服务功能链的架构设计; 第3节中, 详细介绍该服务功能链架构的实现过程; 第4节, 通过设计实验并验证了该架构的可行性和系统性能. 最后, 对下一步工作进行相关介绍.

1 背景 1.1 服务功能链概述

SFC是指定义和实例化一组有序的服务功能, 例如防火墙、深度报文检测系统等, 通过控制网络流量的处理顺序, 高效灵活地为用户提供所需的服务^[2].

IETF对服务功能链进行了标准化定义, 对架构框架、使用场景、路由转发和报文格式等进行了详细阐述^[2]. 图1展示了IETF 提出的SFC架构, 其包括4个核心组件: 分类器(Classifier)、服务功能转发器(SFF)、服务功能(SF)和SFC代理(SFC Proxy). 当数据包进入到一个支持SFC报文的网络区域即SFC-Enabled Domain中后, Classifier根据匹配策略匹配数据包, 将其分配到不同的SFC中; SFF根据SFC报文中携带的信息将数据包转发到一个或多个SF中, 并且处理从SF返回的数据包; SF负责对收到的数据包做特定功能的处理, SF在具体实现的上可以是一个虚拟的元素, 或者是嵌入在具体网络设备上的某种功能, 如防火墙, 深度报文检测系统等; 对于不能识别SFC报文的设备, 可以使用SFC代理.

在服务功能链中, 服务功能路径(Service Function Path, SFP)是指数据包必须按照指定顺序转发的限制规范, 而数据包在网络中实际访问SFF和SF的顺序称为呈现服务路径(Rendered Service Path, RSP). 从SFP到RSP, 是一个从抽象定义到具体实现的逐步细化的过程.

1.2 NSH协议

为引导网络流量在服务功能链的各个逻辑组件中正确传递, 解决SF之间信息交互, 拓扑独立性等问题, IETF提出了用于创建动态服务功能链的NSH协议. 通常, 数据包在网络入口处被添加NSH, 数据平面根据NSH报文完成服务流量的控制和转发. 如图2所示, 一个NSH包含3部分: 四个字节的基本报头、四个字节的服务路径信息和上下文信息(固定长度和可变长度两种). 其中, 四个字节的基本报头提供有关NSH报文本身的信息以及有效负载的信息; 服务路径信息主要是提供服务路径中的路径标识和位置; 上下文信息用来携带元数据(metadata).

2 系统架构设计

在IETF关于服务功能链的RFC文档中提出了服务功能链架构的实现原则, 其中包括拓扑独立性、平面分离、数据包分类和共享元数据等^[2]. 本文基于SDN和NFV技术, 将服务功能链的系统架构分为控制平面和数据平面(图3). 控制平面通过北向接口获取用户对于服务功能链的描述, 生成相应的策略和流表信息, 通过控制平面和数据平面间的南向接口传递到数据平面, 数据平面根据控制平面下发的策略和流表, 将各个逻辑组件实例化, 并使数据包按照指定的顺序经过各个SF, 实现用户所需的服务.

控制平面主要功能包括: (1)提供北向接口, 接收用户对于服务功能链的描述信息; (2)管理底层网络基础设施、链路状态、拓扑结构; (3)负责资源的统一分配, 各个逻辑组件的创建和生命周期的管理; (4)管理SFC的相关信息, 初始化各个监听服务, 持久化相关信息; (5)构建SFP, 生成相关策略和流表; (6)提供南向接口与数据平面进行信息传递. 控制平面通过北向接口, 获取到用户对于服务功能链的描述, 资源管理模块根据描述分配相应的计算和网络资源, SFP路径规划模块根据服务功能链的描述和资源管理模块资源分配结果, 利用Floodlight控制器中原有的对底层网络拓扑管理的模块, 初始化SFP, NSH流表生成模块根据实例化的结果, 生成相应的流表, 通过控制平面和数据平面之间的南向接口下发至数据平面, 控制平面的数据库模块对SFC的相关信息做持久化工作.

当数据包进入数据平面的SFC-Enabled Domain时, 入口处Classifier根据控制平面下发的流表决定哪些包能够进入SFC-Enabled Domain, 并根据下发的匹配规则为这些数据包添加不同的NSH, 转发至相应的SFF中. SFF会根据NSH报文中服务路径标识(Service Path Identifier, SPI)和服务序号(Service Index, SI)确定下一跳地址, 其中, SPI是SFP的唯一标识, SI表示SF在SFP中的位置. 当SF不能识别NSH时, SFF会将数据包发送给相应的SFC Proxy进行处理.

3 系统实现

根据系统的架构设计, 将系统实现分为了控制平面和数据平面的实现两个部分. 控制平面采用Floodlight开源控制器, Floodlight不仅是一款SDN控制器, 它也包含一系列模块化应用, 而这些应用可以向上提供REST API, 从而帮助应用层的应用更好地管控整个网络. POF交换机协议无感知转发的特点, 有效的支持了NSH协议在数据平面的实现, Classifier和SFF等网络功能组件是基于POF交换机开发完成的. 由于控制器主要通过流表的形式对POF交换机进行管理, 因此, 流表生成模块的构建在控制器中十分关键.

3.1 基于Floodlight控制器的控制平面的实现

SFC控制平面主要是基于Floodlight控制器实现的, 用户可以通过控制器提供的北向接口使用SFC的功能, 可以创建、更新或者删除SFC, 自定义非透明的metadata数据字段用来实现SF间的数据共享, Floodlight控制器还可以对底层网络抽象, 获取网络的拓扑结构.

Floodlight控制器提供了一个模块加载系统, 可以方便的利用IOFMessageListener和IFloodlightModule这两个接口进行功能扩展^[9]. 通过实现IFloodlightModule接口, 我们增加了NSH流表生成模块, 将用户对于服务功能链的路径描述信息, 通过流表的形式下发至数据平面, 数据平面的POF交换机根据流表信息对报文添加不同的NSH, 实现数据包在数据平面的传递. 为了实现SFC逻辑组件的自动化部署和管理, 利用python语言编写了资源管理模块. 由于SFC的生成是根据用户的需求来定义的, 因此我们采用了JSON类型的接口格式, 通过JSON接口, 控制平面可以接收来自用户层面的SFC需求描述. 另外, 控制器中还定义了与多个与SFC相关的数据结构, 例如NSH报文信息等.

3.2 NSH流表设计

服务功能链各个逻辑组件对数据包的处理模式可以归结为match-action的处理过程, 即通过匹配数据包中的某个字段, 匹配成功后则用action进行处理, 如Classifier匹配到目的地址A的数据包, 则封装NSH并转发. 因此, 流表的设计主要是对match-action策略的设定.

由于服务功能链中不同的逻辑组件实现的功能不同, 因此下发的流表也不一样. Classifier需要提供对数据包的识别、封装和转发等功能. 本文中Classifier支持对数据包中五元组(目的IP、源IP、目的端口号、源端口号和协议)的识别, 由于POF交换机一次性执行的指令数量的限制, 无法一次性完成五元组的识别和匹配功能, 需要利用多个流表对同一数据包进行处理, 每个流表处理后将结果暂存到POF交换机中的metadata字段中, metadata字段设计如图4所示, 当POF交换机依次将数据包中的五元组写入交换机的metadata字段后, Classifier中负责处理NSH报文的流表利用metadata中的五元组, 根据POF交换机中设定的匹配域, 实现NSH报文的解析与传递.

根据上述分析, 控制平面共下发至Classifier中6个流表, 其处理过程如图5所示, 由于POF交换机接收到的是MAC帧报文, 包括携带VLAN和不携带VLAN字段的两种格式, 因此Classifier中的流表首先是对MAC帧的处理, 从而确定IP报文开始的位置, 接着依次是IP报文和TCP/UDP报文的处理. 五元组写入到POF交换机的metadata中后, 将流表的匹配域与metadata中的五元组相对应, 从而实现对数据包的匹配. 匹配完成后, 利用POF协议无感知转发的特点, 只需要通过AddField、ModifyField和DelField等POF交换机指令便能完成对数据包添加NSH报文头等操作, 不需要对其他代码进行修改, 添加完成后将带有NSH报文转发到不同的SFC中.

在SFC中, SFF根据NSH报文中携带的信息将数据包转发至一个或多个SF中, 并且处理从SF返回的数据包. SFF报文处理流程如图6所示, 当SFF收到报文后, 首先根据NSH报文中的SPI和SI字段确定下一跳地址, 转发到相应的SF或SFF中, 如果SF不支持NSH报文, 则需要先转发到相应的SFC Proxy中将NSH去掉, 转换成SF可以识别的报文, 当SF处理完毕后, SF Proxy需要重新对数据包封装NSH再由SFF转发到下一跳. 由于Classifier不会对匹配策略之外的数据包封装NSH报头, 因此在SFF还需要支持对常规报文的转发.

4 实验设计及验证

为了对该系统的功能和性能进一步分析和研究, 本文设计并搭建了与实际网络环境相近的网络拓扑. 本实验的实验环境使用的是ubuntu14.04的系统, 内核版本是3.13, 网络拓扑利用mininet搭建而成(mininet是一个轻量级的SDN网络研发、仿真以及测试平台). 控制器采用Java语言编写的Floodlight开源控制器, 安装的JDK版本是1.8.

4.1 系统功能测试

本文首先对服务功能链的功能效果进行了实验验证, 实验模拟的是Client请求Web Server服务器的HTTP服务, 其中, Classifier和SFF均基于POF交换机设计而成. 本实验设计了两条服务功能链, 一条功能链SFC1经过的服务功能路径是SF1、SF2、SF3, 另一条经过的服务功能路径SFC2是SF2、SF3. NSH包含3部分: 基本头信息、服务路径信息和上下文信息. 实验中两条服务功能链的SPI分别设为为1和2, SI的初始值设为255, Next protocol设为4(4表示NSH协议), 上下文信息的初始化长度为4个字节固定长度, 初始值为0. 在NSH报文转发表中, 利用SPI、SI和Next Protocol确定下一跳地址, 下一跳地址可以是SF或者SFF, 每次经过一个SF后, SFF负责将SI减1. 在节点通信过程中存在的ARP请求报文, Classifier不会对其进行封装. 表1是控制器下发至SFF1中的NSH报文转发表, 其中*号代表通配符.

实验的网络拓扑如图7所示, 其中Client1主机的IP地址为10.0.0.1, Client2主机的IP地址为10.0.0.2, Server服务器的地址为: 10.0.0.3, 控制器的地址为10.10.28.37. 实验使源IP地址为10.0.0.1的数据包经过SFC1, 源IP地址为10.0.0.2的数据包经过SFC2. 由于mininet网络中的网络设备默认只能添加一条链路, 因此对linux主机添加了虚拟网卡对, SFF和SF间分别关联了虚拟网卡对. 当数据包进入SFC-Enabled Domain后, Classifier根据流表, 匹配数据包并添加NSH, 分别将发自Client1和Client2的NSH中SPI字段设为1和2, 添加完成后, 将NSH报文从 S1-eth3端口转发至SFF1, SFF1根据流表中的Next protocol、SPI和SI确定下一跳地址, 如果匹配到的SPI为1, 则将匹配到的数据包从S2-eth2端口转发之SF1, SF1处理完毕后, 将数据包从F1-eth2端口转发回SFF1, SFF1将数据包中的SI减1后从S2-eth4端口转发到SFF2处, 依次类推, 当SF3将处理完的数据包返回给SFF3时, SFF3去掉数据包的NSH报头后, 转发至web Server服务器. 当SFF1匹配到到数据包中的SPI为2时, 直接从端口S2-eth4转发至SFF2. 在实验中, SF1起到了防火墙的功能, 本文将防火墙规则设置为不允许目的IP地址为10.0.0.3的请求数据包通过, 因此SPI为1的数据包无法收到HTTP响应报文. 此外, Client的发起的HTTP请求报文采用NSH协议进行转发, Web Server返回的数据由于不需要再经过SF, 直接按照常规的数据包进行返回.

实验结果如表2所示, 表中第一条记录是SFC1的HTTP请求结果, 第二条记录是SFC2的HTTP请求结果.

上述实验证明, 基于协议无感知转发的服务功能链实现了IETF提出的有关SFC的标准, 各个逻辑组件功能完备, 并基于POF实现了NSH协议.

4.2 系统性能测试

在性能测试时, 为了更加接近真实的网络环境, 实验利用了一台物理服务器和IXIA网络测量仪对服务功能链的丢包率和时延进行了测试. 实验设计了对照实验, 由于Classifier和SFF是基于POF交换机设计实现的, 因此, 对比了服务功能链环境下和POF交换机环境下, 常规TCP报文和NSH报文的在相同网络环境下的丢包率和时延情况, 实验中数据包的发送速率50 Mbit/s. 图8中左框内是服务功能链性能测试的实验拓扑图, 右框内是POF交换机性能测试的实验拓扑图. 在服务功能链性能测试的实验中, IXIA测试仪的Port0端口不停发送TCP数据包, Classifier对据包封装NSH后转发至SFF, SFF收到NSH报文后, 修改NSH中的SPI字段, 然后去掉数据包中的NSH, 转发至IXIA测量仪的Port1端口. 在对照试验中, TCP数据包直接通过POF交换机转发, 不经过Classifier和SFF.

两组对照实验的报文丢包率均接近于0, 数据包的接收时延如图9所示, 基本趋于一致.

接着, 实验利用iPerf3网络性能测量工具和mininet仿真工具对服务功能链的吞吐量进行了测试, 测试分为两组, 将服务功能链与POF交换机设置为对照实验, 利用iPerf3将数据包的发送速率设置成不同的值, 采用UDP模式进行了测试. 图10的上下两框内分别是服务功能链和POF交换机测试吞吐量时的逻辑拓扑图.

吞吐量的实验结果如图11所示. 从实验结果可知. 在一定范围内, 服务功能链和POF交换机的吞吐量无明显差异, 随着发送速率的提高, 服务功能链网络吞吐量会逐渐下降, 维持在380 Mbit/s左右.

由于Classifier和SFF均是基于POF交换机设计实现的, 根据丢包率、时延和吞吐量的测试结果可知: 在一定的数据包发送速率下, 利用POF交换机实现NSH报文协议后对交换机本身性能没有明显影响, 说明了POF协议能够高效的提供对NSH协议的支持, 避免了OpenFlow协议在扩展过程中的兼容性和实现复杂性等问题. 说明了基于协议无感知转发的服务功能链在性能方面表现优异.

5 结束语

本文根据IETF提出的关于服务功能链的标准, 利用POF协议无感知的特点, 提出基于SDN和NFV架构的服务功能链, 实现了NSH协议, 避免对OpenFlow协议的私有扩展和实现复杂性等问题. 利用Floodlight控制器和POF交换机实现了该服务功能链, 并对其功能和性能分别进行了验证, 实验结果表明, 基于协议无感知转发的服务功能链功能完备, 在性能方面表现优异. 由于本文侧重SDN的实现模块, 对NFV模块的研究不够深入, 也没有考虑到包括故障处理在内的其他因素, 下一步工作将围绕着云计算环境中协议无感知转发的服务功能链的应用进行深入研究.