java无感知部署,基于协议无感知转发的服务功能链
服务功能在部署时, 功能与专属硬件紧密耦合, 每个功能都嵌入在特定的硬件设备中, 导致运营成本不断提高, 网络灵活性变差, 服务部署十分困难[. 为此, IETF提出一种服务功能链(Service Function Chain, SFC)架构来解决服务功能在部署过程中拓扑独立性和配置复杂性等问题[. NSH以一种报头的格式被添加到网络流量中, 用于支持服务功能链架构的实现[.
当前, 利用软件定义网络[(Software Defined Network, SDN)和网络功能虚拟化(Network Function Virtualization, NFV)技术实现服务功能链已经成为了研究热点. SDN和NFV技术高度互补, 彼此互利但并不相互依赖. SDN被视为一种全新的网络技术, 通过分离网络设备的控制平面与数据平面, 将网络能力抽象为应用程序接口提供给应用层, 从而构建开放可编程的网络环境, 在对底层各种网络资源虚拟化的基础上, 实现对网络的集中控制和管理. NFV利用IT虚拟化技术定义网络功能, 通过通用硬件以及虚拟化技术, 来承载相关网络功能, 从而降低网络成本并提升业务开发部署能力, 将硬件和软件解耦, 使网络功能不再依赖于专用硬件.
到目前为止, SFC已经在多个平台上实现, 包括OpenDaylight (ODL)[, ONOS[和OpenStack Networking[. 其中, 只有ODL 平台完全采用IETF SFC架构, 包括所有核心组件、NSH协议等. ODL平台通过对OpenFlow协议的私有扩展实现了NSH协议, 然而, 这种实现方式造成了OpenFlow的兼容性问题. 由于ODL平台中OpenVSwitch(OVS)交换机[通过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是指定义和实例化一组有序的服务功能, 例如防火墙、深度报文检测系统等, 通过控制网络流量的处理顺序, 高效灵活地为用户提供所需的服务[.
IETF对服务功能链进行了标准化定义, 对架构框架、使用场景、路由转发和报文格式等进行了详细阐述[.
图 1
Fig. 1
图 1 SFC逻辑组件
在服务功能链中, 服务功能路径(Service Function Path, SFP)是指数据包必须按照指定顺序转发的限制规范, 而数据包在网络中实际访问SFF和SF的顺序称为呈现服务路径(Rendered Service Path, RSP). 从SFP到RSP, 是一个从抽象定义到具体实现的逐步细化的过程.
1.2 NSH协议
为引导网络流量在服务功能链的各个逻辑组件中正确传递, 解决SF之间信息交互, 拓扑独立性等问题, IETF提出了用于创建动态服务功能链的NSH协议. 通常, 数据包在网络入口处被添加NSH, 数据平面根据NSH报文完成服务流量的控制和转发. 如
图 2
Fig. 2
图 2 NSH报文
2 系统架构设计
在IETF关于服务功能链的RFC文档中提出了服务功能链架构的实现原则, 其中包括拓扑独立性、平面分离、数据包分类和共享元数据等[. 本文基于SDN和NFV技术, 将服务功能链的系统架构分为控制平面和数据平面(
控制平面主要功能包括: (1)提供北向接口, 接收用户对于服务功能链的描述信息; (2)管理底层网络基础设施、链路状态、拓扑结构; (3)负责资源的统一分配, 各个逻辑组件的创建和生命周期的管理; (4)管理SFC的相关信息, 初始化各个监听服务, 持久化相关信息; (5)构建SFP, 生成相关策略和流表; (6)提供南向接口与数据平面进行信息传递. 控制平面通过北向接口, 获取到用户对于服务功能链的描述, 资源管理模块根据描述分配相应的计算和网络资源, SFP路径规划模块根据服务功能链的描述和资源管理模块资源分配结果, 利用Floodlight控制器中原有的对底层网络拓扑管理的模块, 初始化SFP, NSH流表生成模块根据实例化的结果, 生成相应的流表, 通过控制平面和数据平面之间的南向接口下发至数据平面, 控制平面的数据库模块对SFC的相关信息做持久化工作.
图 3
Fig. 3
图 3 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这两个接口进行功能扩展[. 通过实现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
Fig. 4
图 4 交换机中的metadata字段
根据上述分析, 控制平面共下发至Classifier中6个流表, 其处理过程如
图 5
Fig. 5
图 5 Classifier流表处理过程
在SFC中, SFF根据NSH报文中携带的信息将数据包转发至一个或多个SF中, 并且处理从SF返回的数据包. SFF报文处理流程如
图 6
Fig. 6
图 6 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(Table 1)
表 1 SFF1中的NSH报文转发表
Index
Match filed
Action filed
Priority
Protocol
SPI
SI
Input_port
Action
Next hop
0
NSH
01
255
S2-eth1
output (port: S2-eth2)
SF1
100
1
NSH
01
255
S2-eth3
modify (SI-1)output (port: S2-eth4)
SFF2
100
3
NSH
02
255
S2-eth1
output (port: S2-eth4)
SFF2
100
4
ARP
*
*
S2-eth1
output (port: S2-eth4)
20
5
ARP
*
*
S2-eth4
output (port: S2-eth1)
120
表 1 SFF1中的NSH报文转发表
实验的网络拓扑如
图 7
Fig. 7
图 7 实验拓扑
实验结果如
表 2(Table 2)
表 2 Client请求结果
Index
HTTP request
HTTP response
1
Connectting to 10.0.0.3:80
Failed: Connectiontimed out.
2
Connectting to 10.0.0.3:80
200 OK
表 2 Client请求结果
上述实验证明, 基于协议无感知转发的服务功能链实现了IETF提出的有关SFC的标准, 各个逻辑组件功能完备, 并基于POF实现了NSH协议.
4.2 系统性能测试
在性能测试时, 为了更加接近真实的网络环境, 实验利用了一台物理服务器和IXIA网络测量仪对服务功能链的丢包率和时延进行了测试. 实验设计了对照实验, 由于Classifier和SFF是基于POF交换机设计实现的, 因此, 对比了服务功能链环境下和POF交换机环境下, 常规TCP报文和NSH报文的在相同网络环境下的丢包率和时延情况, 实验中数据包的发送速率50 Mbit/s.
图 8
Fig. 8
图 8 丢包率和时延实验拓扑图
两组对照实验的报文丢包率均接近于0, 数据包的接收时延如
接着, 实验利用iPerf3网络性能测量工具和mininet仿真工具对服务功能链的吞吐量进行了测试, 测试分为两组, 将服务功能链与POF交换机设置为对照实验, 利用iPerf3将数据包的发送速率设置成不同的值, 采用UDP模式进行了测试.
图 9
Fig. 9
图 9 时延数据
图 10
Fig. 10
图 10 吞吐量实验拓扑图
吞吐量的实验结果如
图 11
Fig. 11
图 11 吞吐量实验拓扑图
由于Classifier和SFF均是基于POF交换机设计实现的, 根据丢包率、时延和吞吐量的测试结果可知: 在一定的数据包发送速率下, 利用POF交换机实现NSH报文协议后对交换机本身性能没有明显影响, 说明了POF协议能够高效的提供对NSH协议的支持, 避免了OpenFlow协议在扩展过程中的兼容性和实现复杂性等问题. 说明了基于协议无感知转发的服务功能链在性能方面表现优异.
5 结束语
本文根据IETF提出的关于服务功能链的标准, 利用POF协议无感知的特点, 提出基于SDN和NFV架构的服务功能链, 实现了NSH协议, 避免对OpenFlow协议的私有扩展和实现复杂性等问题. 利用Floodlight控制器和POF交换机实现了该服务功能链, 并对其功能和性能分别进行了验证, 实验结果表明, 基于协议无感知转发的服务功能链功能完备, 在性能方面表现优异. 由于本文侧重SDN的实现模块, 对NFV模块的研究不够深入, 也没有考虑到包括故障处理在内的其他因素, 下一步工作将围绕着云计算环境中协议无感知转发的服务功能链的应用进行深入研究.