NFV系统跨数据中心网络连接管理机制

石 峰，蔺婧娜

(1.太原学院 计算机科学与技术系，山西 太原 030032；2.山西工程科技职业大学 信息工程学院，山西 太原 030031)

0 引 言

对于企业用户而言，大规模网络功能部署面临以下几方面的挑战：网络功能数量繁多、网络功能种类多样、网络功能处理逻辑复杂。网络功能的日常运维工作包括网络功能升级、监控诊断、配置调试等多种复杂操作[1-3]。

考虑到本地部署的高昂开销以及复杂操作，越来越多的中小型企业将网络功能外包到云平台，在云服务提供商内部署虚拟网络功能服务。目前已经有大量的云服务提供商为中小型企业提供丰富的网络功能服务，包括运营商(例如：AT&T)以第三方云服务提供商(例如：Akamai，Amazon)等[4,5]。

NFV技术是云计算催生的下一代网络变革。NFV技术可以有效地在云平台进行部署实现，实现虚拟网络功能的按需订购、灵活调度以及便捷管理。目前已经有大量的研究工作致力于实现基于NFV的云平台网络功能高效部署[6-8]。

网络功能调度管理的基本要求是：按照服务功能链信息，实现网络功能连接关系的灵活配置。然而，目前大部分的NFV系统[9,10]均在单一数据中心场景下进行设计，以网络功能为独立单元，在通用数据平面上利用控制器的集中调度管理实现服务功能链部署。

为了实现数据中心灵活连接，用户必须手动建立一个转发表确保数据包在数据中心之间得到正确转发。除此之外，如FlowTag[11]所分析，现实部署存在大量的网络功能在完成数据处理之后输出一些必要的标签，用于保证数据包在之后的正确转发。

本文提出了一个跨数据中心的网络功能连接管理机制——NFVMP(network function virtualization for multiple providers)。NFVMP将每一个数据中心的子链视作一个单元，在每个数据中心内建立与其它数据中心的连接关系，支持跨数据中心服务功能链自动灵活部署，有效提高了网络功能调度管理的灵活性。

1 理论分析

NFVMP系统的基础功能是保障正确性，确保数据包按照服务功能链以正确的转发路径被多个网络功能处理。在本文中，对多数据中心场景下的数据流进行理论建模，并且与传统单一数据中心场景的数据流进行对比分析，从而得出NFVMP系统的设计原则。

1.1 系统模型

(1)

(2)

…

(3)

因此，获得了如下等式

(4)

1.2 正确性分析

企业网用户将网络功能f1,f2,…,fn部署在p1,p2,…,pm数据中心。根据系统正确性，NFVMP必须与传统NFV系统产生相同的数据包处理结果。因此，总结得出了以下的等式

(5)

其中，等式左边代表了NFVMP的数据包结果，等式右边代表传统NFV系统生成的数据包结果。传统的NFV系统将每个网络功能视作独立单元，并致力于解决网络功能部署以及网络功能连接问题。为了让上述公式成立，NFVMP需要将每个数据中心的子链视作独立单元，并且实现以下两步操作：①每一个数据中心生成各自的子链，使得数据包在数据中心内部能够正确地进行处理和转发；②实现子链之间的正确连接。

2 NFVMP设计

在本文节，分别对子链生成、子链连接以及子链更新机制进行具体介绍，其中第2.1节介绍了子链生成机制，第2.2节展示了子链连接机制，第2.3节展示了子链更新机制。

2.1 子链生成

全局服务功能链被分解为两个部分：数据中心A的服务功能子链以及数据中心B的服务功能子链。子链生成算法计算得到的子链需要满足两个要求：①表明数据中心内部实现的网络功能及其转发关系；②表明与其它子链的连接关系。设计了一个子链生成算法，以全局服务功能链为输入信息，计算生成所有相关数据中心的子链。除此之外，为了方便描述输入以及输出信息，设计了一个服务功能链描述语言，能够兼容多数据中心场景。

2.1.1 服务功能链描述语言

在之前的工作中，E2[13]已经设计了一个服务功能链描述语言，能够有效描述所有网络功能以及它们之间的连接关系。然而，出于以下两点考虑，它并不能直接应用在NFVMP系统中：①未说明数据中心相关信息；②未能表达与其它服务功能链之间的连接关系。

这里设计了一种新的服务功能链描述语言，能够有效兼容多数据中心场景。下面展示了服务功能链描述语言的示例。

NF_set: NF1 {DC А}, NF2 {DC B},

NF3 {DC B}, NF4 {DC B};

rule-set { input->NF1,

NF1[cl]-> NF2,

NF2[c2]->NF3,

NF3[c3]->NF4,

NF2->NF4,

NF3->NF4,

NF4->output;]

服务功能链描述语言主要由两个部分组成：NF_set以及rule_set。NF_set包含了所有的网络功能以及它们对应的数据中心信息。rule_set 描述了网络功能之间或者与上流、下流数据中心之间的转发关系。每一条rule都通过以下的格式进行定义：src_node[condition]->dst_node。

与传统描述语言相比，src_node/dst_node可能是上流或者下流数据中心，从而描述与其它数据中心之间的连接关系。例如：“dc A[c1]->NF2”表示从数据中心A发出并且携带cl标签的数据包发送到NF2进行后续处理。如果condition为空，那么表示在默认情况下并不需要对数据包进行过滤处理。

2.1.2 子链生成算法

算法1展示了提出的子链生成算法。根据输入的全局服务功能链，该算法为所有相关数据中心生成各自的子链。其中第(2)行～第(3)行用来生成所有数据中心的NF_sets。剩下的部分用于生成rule_sets。对于rule_set中的规则符合以下任何一个条件：①src_node以及dst_node隶属于同一个数据中心；②src_node是input；③dst_node是output，则直接添加该规则到唯一存在的数据中心的子链中。如果src_node与dst_node不隶属于同一个数据中心，那么将产生两条规则并分配到两个子链中。第一条规则加入到src_node的数据中心子链中，dst_node被dst_node的数据中心代替。第二条规则加入到dst_node的数据中心子链中，src_node被src_node的数据中心代替。

客户端通过上述子链生成算法得到所有相关数据中心的子链，并将其通过特定的接口下发到各个数据中心进行后续子链部署。

算法1：子链生成算法

输入：全局服务功能链描述(NF_set and rule_set)；

输出：每个数据中心的子链描述(NF_set and rule_set);

初始化：每个数据中心子链：NF_set, rule_set∅，∅;

(1)functionChainPartition(NF_set, rule_set)

(2)forNF∈NF_ENF_setdo

(3) 添加NF到NF.dc的NF_set;

(4)forrule∈rule_setdo

(5) src_node, dst_node←rule.src_node, rule.dst node;

(6)ifsrc_node = input or src_node.dc= dst_node.dcthen

(7) 添加rule 到dst_node.dc的rule_set;

(8)elseifdstNode = outputthen

(9) 添加rule 到src_node.dc的rule_set;

(10)else

(11) 添加(src_node[rule.condition]→dst_node.dc)到

(12) src_node.dc 的rule_set;

(13) 添加(src_node.dc[rule.condition]→dst_node)到

(14) dst_node.dc 的 rule_set;

(15)return每个数据中心的NF_set and rule_set;

2.2 子链连接

对于传统的NFV系统，网络功能全部部署在通用数据平面上，控制器通过数据平面交换机配置网络功能之间的连接关系。然而，在多数据中心场景下，独立自治的数据中心使得通用数据平面以及集中控制器均无法实现。除此之外，现实部署中存在大量状态相关的网络功能，其输出的状态信息决定后续的数据包转发路径。这类网络功能使得子链连接更加复杂。下面小节，将对以上两个挑战进行具体分析，并提出相应的解决方案。

2.2.1 数据中心间转发策略

由于缺乏集中控制器以及通用数据平面，无法采用集中式的方法实现子链连接。采取分布式的方法将此问题分解为两个子问题：①上流数据中心将数据包转发到正确的下流数据中心；②下流数据中心将数据包转发到正确的网络功能。下面，将分别对两个子问题进行具体说明。

当上流数据中心内的所有网络功能完成数据包处理之后，数据中心需要将数据包转发到下流数据中心进行后续处理。因此，在出口处安装转发器来建立数据包标签与下流数据中心的转发关系。数据包标签能够唯一确定下一个网络功能，也就可以唯一确定下流数据中心。当数据中心从网卡收到数据包时，在入口处安装分类器，从而正确地将数据包转发到下一个网络功能。分类器建立了上流数据中心、数据标签与下一个网络功能之间的绑定关系。上流数据中心与数据标签能够唯一地对下一个网络功能进行确认。

算法2：分类表和转发表生成算法

输入：子链描述(NF_set and rule_set);

输出:分类表和转发表;

(1)functionTableGeneration(NF_set, rule_set)

(2)forrule∈rule_setdo

(3)ifrule.src_node ∉NF_setthen

(4) 添加(rule.src_node, rule.condition, rule.dst_node)到分类表;

(5)elseifrule.dst_node∉NF_setthen

(6) 添加规则(condition, rule.dst_node)到转发表;

(7)else

(8) 跳过这条规则;

(9)return分类表和转发表；

算法2展示了分类表和转发表生成算法。该算法根据下发的子链信息，生成每个数据中心的分类表和转发表。其中，第(3)行～第(4)行用于分类表的生成，第(5)行～第(6)行用于转发表的生成。如果一条规则的src_node不属于本地数据中心并且dst_node属于本地数据中心，那么一条分类表的表项生成。上流数据中心由src_node的地址表示，标签通过规则的condition信息生成，网络功能由dst_node生成。同理，如果一条规则的dst_node不属于本地数据中心并且src_node属于本地数据中心，则生成一条转发表的表项。其中，标签由规则的condition生成，下流数据中心由dst_node生成。

2.2.2 数据包标签处理策略

如FlowTag所述，现实部署中存在大量的网络功能在对数据包处理之后生成一些标签信息，用于指导数据包的后续转发路径。对于NFVMP，生成的数据包标签可能会影响到数据包在其它数据中心内的转发路径。本文基于FlowTags设计了数据包标签处理策略，从而支持多数据中心场景。

数据包标签需要考虑以下3个方面的问题：①网络功能生成状态标签；②网络标签对网络功能数据处理的影响；③网络标签对转发策略的影响。对于第一个方面，NFVMP采用了FlowTags类似的策略进行标签存储。对于IPv6协议，利用20比特的flow label字段来存储；对于IPv4协议，利用8比特的TOS字段进行存储。对于第二个方面，生成的网络功能可能对下流网络功能的数据处理产生影响。因为，在整个数据处理的流水线中，生成的数据包标签始终保存并且不会删除。对于第三个方面，数据包的标签信息可能对数据中心之间的转发产生影响。在NFVMP设计中，在分类器和转发器中包含标签信息，从而支持数据中心之间根据状态信息进行转发。

2.3 子链更新

上述子链生成与子链连接策略均基于静态不变的服务功能链进行实现。然而，在现实部署中，服务功能链会随着时间动态变化，从而满足用户的不同时刻需求。NFV系统设计需要支持灵活变化的服务功能链，包括动态增加或者删减的网络功能或者转发关系变化。

一种简单直白的解决方案是按照更新的服务功能链，将所有网络功能重新在底层进行部署，重复之前的子链部署与子链连接过程。然而，这种方式导致大量的时间消耗与资源浪费。在本文，设计了一种增量策略更新方法，计算每个数据中心需要变更的策略，包括删除的规则以及增加的规则等。客户端根据新旧服务功能链分析计算子链更新内容并进行下发，数据中心则对接收到的更新策略进行实际部署。下面部分，将从这两方面进行具体分析。

2.3.1 子链更新策略分析

客户端负责分析所有子链的更新策略，也即网络功能集变更NF_set(包括added_NF_set和expired_NF_set),以及规则集变更rule_set(包括added_rule_set和expired_rule_set)。算法3展示了子链更新算法，输入是两个服务功能链(原服务功能链与新服务功能链)的子链更新策略算法，输出是所有相关数据中心的增量更新策略。其中第(2)行～第(5)行根据算法1生成两个服务功能链的子链。第(7)行～第(11)行通过GetExpiredAddedSet函数生成所有数据中心的子链更新信息。其中GetExpiredAddedSet函数的功能是通过old_set与new_set的对比，生成expired_set与added_set。GetExpiredAddedSet通过如下的方法进行计算(见算法3的A1至A18行)：首先，old_set与new_set分别按照字典序进行排序，然而对其中的每一条规则同步进行浏览。如果old_rule与new_rule相同，那么做跳过处理，将两条规则都在集合中删除。如果old_rule小于new_rule，那么将old_rule添加到expired_set中。否则，将new_rule添加到added_set中。

2.3.2 子链更新策略部署

上述算法生成了所有数据中心的子链更新策略，包括add_NF_set、expired_NF_set、add_rule_set以及expired_rule_set。每个数据中心基于接收到的子链更新策略进行增量部署，包括以下几方面：①添加或者移除网络功能；②修改网络功能之间的转发关系；③修改与其它数据中心之间的转发关系。如果src_node与dst_node全部是网络功能类型，那么做第一类或者第二类重新配置，在每个数据中心内进行完成配置。如果src_node属于input、output或者dc类信息，那么需要进行第三类更新配置，对分类表和转发表进行修改，改变与邻居数据中心之间的数据包转发关系。

算法3：子链更新算法

输入：旧服务功能链描述(old_NF_set and old_rule_set);

新服务功能链描述(new_NF_set and new_rule_set);

输出：每个数据中心的增量更新子链

(expired_NF_set, expired_rule_set, added_NF_set, added_rule_set);

初始化：每个数据中心的增量子链：

expired_NF_set, expired rule_set, added_NF_set, added_rule_set←∅, ∅, ∅, ∅;

(1)functionChainUpdate(old_NF_set,old_rule_set,new_NF_set, new_rule_set)

(2) ChainPartition(old_NF_set, old_rule_set)

获得dc_set_old以及子链;

(3) ChainPartition(new_NF_set, new_rule_set)

获得dc_set_new以及子链;

(4) dc_set←(dc_set_old)∪(dc_ set_ new);

(5)fordc∈dc_ setdo

(6) dc.expired_NF_set, dc.added_NF_set ←

(7) Comparison(dc.old_NF_set, dc.new_NF_set);

(8) dc.expired_rule_set, dc.added_rule_ set)←

(9) Comparison(dc.old_rule_set, dc.new_rule_set);

(10)return每个数据中心：expired_NF_set, added_ NF_ set,

(11) expired_rule_set, added_rule_set;

A1：functionComparison(old_set, new_set)

A2： expired_set, added_set←∅, ∅

A3: old_sorted_queue = SortInLexicographicOrder(old_set);

A4: new_sorted_queue = SortInLexicographicOrder(new_set);

A5:while(old_sorted_queue != ∅)and

(new_sorted_queue!= ∅)do

A6: old, new←old_sorted_queue.first,

new_sorted_queue.first

A7:ifold == newthen

A8: 从old_sorted_queue 移除old;

A9: 从new_sorted_queue 移除new;

A10:elseifold < newthen

A11: 添加old 到expired_set;

A12: 从old_sorted_queue 移除old;

A13:else

A14: 添加new到added_set;

A15: 从new_sorted_queue移除new;

A16: 将old_sorted_queue的所以规则添加到expired_set;

A17: 将new_sorted_queue 的所以规则添加到added_set;

A18:returnexpired_set, added_set;

3 原型系统实现

在DPDK[16]以及OpenNetVM[14]的基础上，对NFVMP进行了原型系统实现。在一系列的服务器上进行了开发部署，以下是每个服务器的硬件信息：两块Intel(R)Xeon(R)E5-2620v3 CPU(2.40 GHz,12核)，64 G RAM以及两个10 G网卡。这些服务器都运行在Linux操作系统，其内核版本为3.10.0。

在实现的原型系统中，每一个服务器作为一个单独的数据中心，与其它的数据中心进行直连。在每一个数据中心内，基于OpenNetVM运行一个单独的NFV系统。在每个NFV系统内，采用Docker[14]技术进行网络功能实现，从而保证每一个网络功能在单独的核内运行。除此之外，将分类器和转发器也在Docker内运行，分别占用一个物理核。Docker方式能够保障物理核不会被操作系统等其它任务所占用。

针对原型系统性能测试，基于MoonGen[15]进行流量生成。MoonGen是一个基于DPDK的流量生成器，在单独的服务器上运行并且与其它服务器进行直连。流量生成器发送与接收生成的数据包，从而对系统的性能包括时延和吞吐量进行测量。

为了验证NFVMP原型系统的性能，对以下4个网络功能进行了实现：虚拟专用网络、深度包检测、网络缓存以及网络监控。上述网络功能采用图1的方式进行部署与连接。其中数据中心A负责前两个网络功能，数据中心B负责后面两个网络功能。从数据中心A流出的数据包如果目的端口是80，那么发送到网络缓存，否则发送到网络监控进行后续处理。

图1 NFVMP原型系统部署的服务功能链

将NFVMP系统与OpenNetVM进行对比。对于OpenNetVM系统而言，所有的网络功能在一个数据中心内运行，可以作为最佳模式。通过对比，可以得知NFVMP系统与最佳模式之间的差距。

4 验证与评价

在本文中，从以下几个方面对NFVMP系统进行了性能评价：

验证了NFVMP可以跨数据中心实现数据包的正确转发，与传统的NFV系统产生相同的数据包处理结果。

评估NFVMP加入的3种算法运行时间开销，包括子链生成算法、分类表和转发表生成算法和子链更新算法。

评估NFVMP在数据层的性能开销，包括变化的数据包大小、网络功能数量以及数据中心数量对性能结果的影响。

验证NFVMP系统在数据中心真实流量条件下的系统性能，包括数据包处理时延和吞吐量。

4.1 正确性验证

生成一系列的数据包，并且在数据包负载中标记序列数字。将生成的流量分别发送到NFVMP以及OpenNetVM系统中，并且将最终的数据包结果进行对比分析。最终结果表明，NFVMP与OpenNetVM系统能够得到相同的数据包结果，符合正确性准则，有效地提高了网络功能跨数据中心调度的灵活性。

4.2 算法性能

在本节，对3种算法运行时间进行了评估，包括子链生成算法、分类和转发表生成算法以及子链更新算法。

图2展示了上述3种算法的运行时间与连接数之间的对应关系。两种算法的运行时间均在毫秒数量级。例如：对于一个1000条连接数的服务功能链，子链生成算法消耗1.69 ms进行服务功能链分解，分类表和转发表生成算法花费1.21 ms进行表生成，子链更新算法则花费6.45 ms来生成所有子链的增量更新策略。除此之外，网络连接数与运行时间呈现线性增加的趋势。上述时间开销均发生在系统运行之前。对于NFV系统若干分钟启动时间而言，毫秒级别的时间是微不足道并且可以忽略不计的。

图2 控制层算法性能

4.3 数据层性能

相比于传统的NFV架构，NFVMP系统在数据层带来调度管理灵活性优势，使得服务功能链跨数据中心灵活部署。但是，NFVMP方案也给数据层性能带来了一定的负载，并主要体现在以下两方面：①数据中心间的数据包转发；②数据中心内的表查询。第一点的主要决定因素在于数据中心间的网络通信资源，与NFVMP机制的设计无关，必须通过改良网间通信资源来提升性能。第二点的主要决定因素则是NFVMP设计带来的分类器和转发器。因此，在本文节，对表查询造成的性能负载进行测量，并与最佳模式进行性能对比分析。

4.3.1 数据包大小的性能影响

使用64字节到1500字节的数据包来测试数据包大小对系统性能的影响，包括数据包处理时延和吞吐量。图3的实验结果表明：对于任意数据包大小，NFVMP均只引入极小的时延大约1.8μs。图4表明了数据包大小与吞吐量之间的对应关系。随着数据包大小的增加，NFVMP引入的网络拥塞被缓解，与最佳模式的性能越来越接近。对于最差的结果(对应于64字节)，吞吐量下降比例是2.24%。如果数据包大小超过512字节，NFVMP与最佳模式的性能几乎相同。

图3 数据包大小对时延的影响

图4 数据包大小对吞吐量的影响

4.3.2 网络功能数量的性能影响

在此实验中，采用了2个～6个相同的网络功能，分布在两个数据中心内进行部署。所有的网络功能全部都是网络缓存，并且数据包大小全部采用256字节。如果网络功能的总数是偶数，两个数据中心进行均匀分布，如果是奇数，那么数据中心A比数据中心B多部署一个网络功能。图5和图6分别展示了网络功能数量与时延、吞吐量之间的对应关系。在时延方面，对于所有的功能数量，NFVMP的时延开销均为1.8μs。在网络功能数量为4时，吞吐量下降率为3.51%。随着网络功能数量的增加，NFVMP与最佳模式的性能越来越接近。网络功能数量越多,系统性能瓶颈在于多个网络功能的数据处理，而不是分类器和转发器造成的数据查询工作。

图5 网络功能数量对时延的影响

图6 网络功能数量对吞吐量的影响

在此实验中，验证了NFVMP向多个数据中心扩展的能力，并测试了数据中心数量变化带来的性能开销。采用图1的服务功能链，以及256字节的数据包进行实验测量。对于4个网络功能的服务功能链，最小的数据中心数量是1，最大的数据中心数量是4。图7和图8展示了网络功能数量与时延、吞吐量之间的关系。每增加一个数据中心，系统时延增加1.8μs，吞吐量下降0.82%～26%。对于NFV系统而言，为了更好地满足用户需求提高网络功能调度灵活性，这些微小的性能负载是可以忽略不计的。

图7 数据中心数量对时延的影响

图8 数据中心数量对吞吐量的影响

4.3.3 真实网络流量测试

在本文节，在数据中心的真实网络流量上进行了性能测试以及性能比较。根据数据中心测量工作中分析的数据包大小分布情况，生成大量符合真实数据包大小分布的流量进行测试。与最佳模式系统相比，NFVMP仅仅引入了1.8μs的网络时延，对于真实系统部署是可以忽略不计的。两个系统的吞吐量几乎相同，并没有带来明显性能下降。

综上所述，对NFVMP系统从几个方面进行了验证工作：

正确性：NFVMP实现了数据包在多个数据中心之间的正确路径转发，有效地提高了网络功能调度灵活性；

系统性能：与最佳模式相比，NFVMP在控制层以及数据层引入的性能负载极小，几乎可以忽略不计。

5 结束语

本文设计了一个跨数据中心的网络功能连接管理机制——NFVMP。通过理论分析，得出NFVMP的设计原则是将每个数据中心的子链视为一个独立单元，并且实现子链生成、子链连接与子链更新。对于子链生成，NFVMP设计了一个子链生成算法用来计算所有相关数据中心的子链。对于子链连接，考虑到没有集中控制器以及通用数据平面实现网络功能连接，采用了分布式方法进行网络功能灵活连接。每个数据中心通过分类器和转发器建立与上流、下流数据中心之间的连接关系。除此之外，设计了一个增量式的策略更新算法来动态地对子链进行更新。基于OpenNetVM系统对NFVMP进行原型系统实现。实验结果表明,NFVMP在多数据中心场景下能够实现网络功能灵活连接，其带来的性能开销非常微小，几乎可以忽略不计。