0、引言

目前，广电网络业界正在研究于双向有线电视网络中部署NFV（网络功能虚拟化）/SDN（软件定义网络）技术的方案。那么，如何把双向有线电视接入网MAC虚拟化，虚拟化之后的性能如何，由性能评估结果能得出什么结论，是本文探讨的内容。

1、在DOCSIS MAC中部署NFV技术的方案探讨

DOCSIS MAC（媒介接入控制层）由数据平面、控制平面及管理平面组成，目前，在最新的CCAP（融合型双向有线电视网络接入平台）产品之中，其中的控制平面与管理平面都已经以软件的形式来实现，但是数据平面仍然是靠硬件来实现以保证高吞吐及低延迟/时延。

把CCAP平台作虚拟化处理，就是把DOCSIS的MAC上移至云端。而在此之前，需要首先考量虚拟化MAC的成本及虚拟化之后的性能。

为了评估把DOCSIS MAC虚拟化需要多少通用的CPU核、虚拟DOCSIS MAC能达到多大的性能，首先就需要把DOCSIS MAC分解成多个功能模块，然后为每个模块创建由数据分组/包驱动的NFV仿真模型，并通过仿真获得整个上行及下行MAC数据路径的CPU周期消耗，基于此类数据，就可获知给定X86通用服务器对于不同大小的数据包的吞吐性能。

1.1 DOCSIS MAC功能模块的分解

同其他双向有线电视接入网络技术（比如无源光网络PON）的MAC层相比，DOCSIS的MAC协议相当复杂。包括上行与下行数据平面、DOCSIS MAC控制平面与管理平面等所有DOCSIS MAC功能模块。

（1）DOCSIS下行数据平面的虚拟化

目前，DOCSIS下行与上行数据平面均是通过硬件（FPGA芯片或ASIC芯片）来实现的。根据DOCSIS MULPI规范，DOCSIS下行数据帧的处理过程包括以下步骤：

①以太网RX MAC：其从IP路由器接收L2（第二层）以太数据包；

②业务流分类：业务流分类器搜索MAC地址表，并首先获得目的地CM（双向有线电视宽带接入网络终端）的ID（标识符），然后基于CM分类档决定数据包的SFID（业务流标识符），同时获得QoS（服务质量）属性；

③下行调度：下行调度器根据QoS属性把数据包分配至相应的下行序列，并基于特定算法及规则来调度数据包；

④绑定信道分配：绑定信道分配器基于预先设定的负载均衡策略，把数据包分发至不同的下行绑定信道（于其中，DOCSIS MAC管理包通常比其他类型的数据包具有更高的分配优先级）；

⑤AES/DES加密：以某个CM特有/独有的关键字对数据包进行加密处理；

⑥DOCSIS成帧：DOCSIS成帧器为每个下行数据包加上DOCSIS头部；

⑦MPEG-2成帧：MPEG-2成帧器把DOCSIS数据流分切成184字节长度的MPEG-2帧，并加上4字节长度的MPEG头部（注：仅有DOCSIS 3.0及其以下版本的DOCSIS技术才具备这一步骤，而最新一代的DOCSIS 3.1系统则不再有MPEG-2成帧器）；

⑧DEPI封装：DEPI封装器把DOCSIS下行数据包或MPEG-2帧封装进MAC层与PHY（物理层）之间的L2TP隧道链路。

（2）DOCSIS上行数据平面的虚拟化

虽然有一些小的差别，但是DOCSIS上行数据平面的处理流程基本上是上述的DOCSIS下行数据平面流程的相反过程，如下所述：

①UEPI解封装：UEPI解封装器去除L2TP头部并获得DOCSIS或MPEG数据帧；

②突发数据包拼接：其把DOCSIS上行的突发数据拼接起来；

③DOCSIS解帧：DOCSIS解帧器进行CRC校验，并去除DOCSIS头部；

④AES/DES解密：其对每个DOCSIS业务流的上行帧作解密处理；

⑤帧分配：帧分配器从中数据流中提取出DOCSIS管理消息，并将这些消息转发给DOCSIS控制与管理软件；

⑥上行调度：DOCSIS上行调度器把各个上行数据包调度至相对应的优先级序列缓冲器；

⑦以太网TX MAC：其把上行L2数据包转发至IP路由器。

（3）DOCSIS MAC控制平面的虚拟化

与静态业务配置功能不同的是，DOCSIS MAC控制模块的运行是实时、动态的，由上层业务应用或者MAC内部消息触发。例如，以VoIP来对通话进行初始化、CM请求CTMS为其分配某个数值的上行带宽、组播视频APPs（应用）向平台请求分发某个电视节目等。DOCSIS MAC控制模块以软件线程的形式运行于具备实时OS（操作系统）或NP（网络处理器）的CPU，通常无需消耗太多的CPU周期，但是常需要进行对于各种请求的及时响应。实际上，DOCSIS MULPI标准中详细规范了DOCSIS控制功能，下面对每个DOCSIS MAC控制模块作简要介绍：

①上行调度器：其接收来自于所有CMs终端的BRM（带宽请求消息），并于每个调度周期内为各个CM计算上行带宽授权；

②动态业务流变更：其可实时、动态地创建、变更或删除业务流。通常，策略服务器向CCAP平台发出更改业务流的指令；

③负载均衡：其为CCAP平台的一大功能特性，用于对CM终端所使用的一组下行及上行信道的动态变更进行控制；

④多播/组播控制：其对来自于CPE（用户侧视听终端）的组播组加入/离开请求作及时响应；

⑤密钥交换：其用于依据BPI+标准来周期性地更新CM加密密钥；

⑥CM控制：其在CM开机的时候对CM授权，并对CM终端与CCAP平台之间的连接进行监控。

（4）DOCSIS MAC管理平面的虚拟化

DOCSIS MAC管理平面用于对DOCSIS信道、MAC域服务组、QoS、DOCSIS  3.1射频调制级别等不同参数进行配置。通常，大多数的配置很少需要进行变更，除非双向有线电视宽带接入网络运营商要延伸下行或上行信道编号、为某种新兴业务增添相应的QoS策略等。因此，DOCSIS MAC管理功能模块均是常规的软件线程，并无严格的实时、动态需求。

1.2  DOCSIS MAC虚拟化工具：NFV的DPRK框架

NFV旨在试图将传统的网络设备替换为通用的X86 CPU及各个软件功能，其所采用的通用硬件设备可以是物理服务器或者云计算中心里的虚拟计算资源。双向有线电视宽带接入网络运营商之所以青睐NFV技术，是因其从专用硬件设备中解耦出了网络功能，并由此提供了一种全新的网络服务设计、部署及管理的方式。

DPRK（Data Plane Development Kit，数据平面开发工具包）被业界广泛地应用于面向Intel X86的NFV编程框，其为第三方开发者提供了数据平面功能库及以太驱动（运行于Linux用户空间，进行快速的数据包处理），可促进各种高速数据包网络应用的快速开发。

为了对虚拟化DOCSIS MAC的性能进行评估，工程师将原始的基于硬件（FPGA）实现的DOCSIS MAC数据平面功能模块更换为基于DPDK框架的软件单元，并试图获取每个DOCSIS MAC数据包处理单元的CPU指令周期消耗。 

2、对虚拟化DOCSIS MAC的性能的评估

创建一个真实、完整的DOCSIS MAC软件并搭建一个端到端级别的测试系统是相当具有挑战性的。本文中所述的性能评估仅基于模块单元级别的真实测试，并将测试结果集中起来，以此分析DOCSIS MAC系统性能。测试中所采用的通用硬件设备是华为公司的FusionServer RH2288，其具备Intel Xeon 12核的2.6 GHz 64位处理器，8个10 GE NIC（网卡）以及128GB的RAM。

2.1 对DOCSIS MAC数据平面性能的评估

对数据面的性能评估是最难的，需要设计非常好的软件处理流程及任务以获得高吞吐及低延迟/时延性能。为了作出尽可能准确的评估，工程师采取DPDK功能库中优化的API（应用编程接口）来实现序列调度、分类及数据包切片模块，以此来保证高的处理性能、进行AES加密与解密。为此，工程师们选择了Intel的AES-NI功能库（面向各类安全应用而设计的一组特殊指令集）。

DOCSIS MAC数据平面功能模块以数据包为单位对数据进行处理及转发，其中，软件转发性能与数据包的大小相关。因此，在性能评估中，工程师分别选取了具有代表性的64字节数据包、128字节数据包、256字节数据包、512字节数据包、1024字节数据包、1518字节数据包及2000字节数据包来输入，然后对处理周期作计数处理。很明显的是，越大的数据包，其比特率吞吐量就越高。表1及表2给出了2000字节数据帧（最新一代双向有线电视宽带接入网络标准DOCSIS 3.1 MULPI所规范的最大规格的数据包）的下行及上行处理周期。从中可看出，DOCSIS下行方向及上行方向的计算成本非常相近，而且，AES加密与解密消耗掉了多于一半的计算资源。

表1  DOCSIS下行数据平面的CPU周期[3]

表2  DOCSIS上行数据平面的CPU周期[3]

表3给出了传输不同长度的数据包时，DOCSIS下行与上行数据平面的CPU周期总数。

表3  典型长度数据包的CPU周期[3]

2.2 对DOCSIS MAC控制及管理平面性能的评估

与DOCSIS MAC数据平面不同的是，DOCSIS MAC控制及管理平面的软件线程是由事件而非数据包来驱动的。这些事件通常随机出现，而且不能以数据包吞吐性能来测量。实际上，DOCSIS MAC控制及管理功能模块仅需要实时运行，且不会消耗掉太多的计算资源（上行调度模块除外）。因此，工程师决定把上行调度器代码移植到X86处理器，并通过真实测试来评估其性能。但是至于其他的DOCSIS MAC控制及管理功能模块，则很难将其全部移植到X86处理器，所以，工程师通过现有设备中的CPU负载经验数据来估量计算成本。

DOCSIS的上行调度是周期性的，上行调度器收集来自所有CM用户终端的请求，并在每个周期内指配授权。调度周期的时间长度将会对数据流量的上行延迟/时延带来影响——通常地，DOCSIS的上行调度周期一般被设置为1.5毫秒到两毫秒。上行调度器的计算资源消耗量与其所覆盖/支撑的CM终端数量是相关的。

对于其他的除了DOCSIS上行调度器之外的DOCSIS MAC控制及管理功能，将其运行于具备1.2 GHz速率的ARM处理器。通过测试发现：如果有1000台CMs终端同时工作，且每台CM有4个上行业务流、4个下行业务流，那么，在数据流量的峰值时间段及闲时时间段，CPU的使用率分别为70%及20%。

于是，假设部署于数据中心里的X86 CPU可被设计为具有100%的使用率，而2.6 GHz的X86 CPU的计算能力是1.2 GHz RAM的3.2倍（前提是两者均运行相同的测试代码），这样，就可估算出1个X86 CPU核支撑1000个CMs终端时的性能：70%÷3.2≈0218。

3、对上文所评估出的性能数据的分析

DOCSIS数据平面的CPU消耗量与数据包的长度是相关的。在实际的数据流量中，以太数据包的长度从64字节到1518字节不等。典型地，工程师通常选择如表4所示的iMIX档作为双向有线电视宽带接入网络的数据包长度分布模型，于是，CPU的消耗就可以通过这个式子进行计算：

表4  不同长度接入网数据包的分布

如果把上文表3及表4的数据输入到上面的数学计算式之中，就可得出DOCSIS上行数据平面是7.55（周期/bps）、DOCSIS下上行数据平面是7.7（周期/bps）。

于是，假设DOCSIS接入网的下行带宽数值与上行带宽数值的比值为5:1、X86处理器的速率为2.6 GHz，就可以计算出获得/达到1 Gbps速率所需的X86 CPU核数。具体如下：

X86 CPU核数/Gbps=（1 Gbps×7.7+1 Gbps×0.2×7.55）÷2.6 GHz=3.54

那么，整个DOCSIS MAC软件所消耗的CPU核数的计算式就可表达为：

所需总核数=3.54×T+0.556×C+0.218×C

其中，“T”为吞吐量（以Gbps为单位）、“C”为CMs终端的数量（以“千”为单位）。

假设3条CPU消耗曲线，分别对于接入有1万家庭用户的小型局端、3万家庭用户的典型局端、5万家庭用户的大型局端。假定接入3万家庭用户的DOCSIS局端具有80 Gbps的带宽，那么，虚拟化的DOCSIS MAC就需要大约300个X86 CPU核或者25台具备2U高度的华为Fusion服务器。

如果将在X86 CPU、FPGA、ASIC上来实现DOCSIS MAC时所需功耗的对比，通过通用的X86 CPU来实现时，达到每Gbps带宽的功耗为38.35瓦，相比于FPGA（1.6瓦）及ASIC（0.48瓦）实现时的功耗的确要高出很多。

4、总结

通过部署NFV技术，可以把各种网络设备改型为通用硬件+特定软件。对于某些网络设备而言，对其做虚拟化处理可以以低的成本换取巨大的效益提升，但是对于某些网络设备则不然。

上文详细介绍了对于基于通用CPU的DOCSIS MAC进行虚拟化之后的性能评估，结论是DOCSIS MAC通过通用服务器来实现与传统上通过FPGA来实现时存在大的差距——达到相同的带宽时，前者的功耗是后者的24倍。

相信在未来，基于通用服务器的DOCSIS MAC的性能将会得到很大程度的提高，但上一段中所提及的“24倍”这个差距在短期内是很难“填平”的。

“基于通用X86服务器实现DOCSIS MAC”这一新兴方案于成本方面缺乏市场竞争力的根本原因在于：目前，部署于云计算中心的通用X86服务器均为设计为支撑对于计算性能及存储性能有着巨大需求的那些网络应用。而双向有线电视宽带接入网络的转发设备则往往不需要多大的计算性能和存储性能。

所以，预计：如果将来能够研发出专门为双向有线电视网络转发设备“量身”定制的新型通用硬件平台，那么，以NFV技术来虚拟化DOCSIS MAC的方案就将广为市场所接受。

参考文献：

[1] 李远东. 双向有线电视网络接入网现状与趋势（十一）：对于融合型双向有线电视网络接入网平台CCAP的虚拟化的探讨[EB/OL].

http://www.istis.sh.cn/list/list.aspx?id=8666, 2015-05-29.

[2] 李远东. 双向有线电视网络SDN架构技术报告（一）：背景与总体架构[EB/OL].

http://www.istis.sh.cn/list/list.aspx?id=8742, 2015-07-31.

[3] Li Zhang, Xin Yang, Lifan Xu. Evaluation of virtualizing DOCSIS MAC by software in data center[C]. 2016 Spring Technical Forum Proceedings, 2016-06-20.