算力网络发展中的若干关键技术问题分析

算力网络是指在计算能力不断泛在化发展的基础上，通过网络手段将计算、存储等基础资源在云、边、端之间进行有效调配的方式，以此提升业务服务质量和用户的服务体验。

算力网络自2019年诞生至今已有3年多，在产业界的共同努力下，算力网络技术研究在国际和国内都取得了显著的进展。国际上，互联网工程任务组（Internet Engineering Task Force，IETF）已经开展了计算优先网络框架（computing first network framework）系列研究；欧洲电信标准组织（European Telecommunication Standards Institute， ETSI）和宽带论坛（Broadband Forum，BBF）分别启动了NFV-EVE020和SD-466相关技术研究；国际电信联盟电信标准化部门（International Telecommunication Union Telecommunication Standardization Sector，ITU-T）也发布了Y.2501（computing power network-framework and architecture）的技术标准。在国内，三大运营商与中国通信标准化协会（China Communications Standards Association， CCSA）同期开展了包括算力网络需求与架构、算力路由协议技术、算力网络标识解析技术、算力网络控制器技术、算力网络交易平台技术、算力网络管理与编排技术、算力度量与算力建模技术等全方位的标准技术研究工作，有力地推动了算力网络的发展。

2021年，算力网络借助“东数西算”的国家战略迎来蓬勃发展的一年，中国联通提出基于第三代面向云的无处不在的宽带弹性网络（cloud-oriented ubiquitous broadband elastic network 3.0，CUBE-Net3.0）打造新一代数字基础设施建设，通过“联接+计算”的算网一体理念，以云网为基、数智为核，实现算网联动；中国电信提出了“网是基础、云为核心、网随云动、云网一体”的思路，以云为核心大力发展云网融合；中国移动则提出了算力立体泛在、算网融合共生、算网一体服务的新理念。虽然三大运营商对于算力网络的立足点有所不同，但是核心思想趋于统一，都是希望未来云、网、算等资源能够融为一体，使用户能够像用电、用水一样，随时随地地使用算力。

为实现此愿景，产业界先后提出了如下主要技术思想。

● 抽象出算力的计量粒度，使得算力资源的度量能够在一定程度上统一。

● 算力优先网络的实现，使得网络中的路由计算不再只依靠传统的链路度量值，而能够将算力信息作为权重参与路径选择。

● 通过网络在云侧、边侧、端侧的高效分布和连接保证，使得“多云协同”“云-边协同”“端-云协同”成为现实。

● 算力网络管控系统的统一管理和编排完成算力、网络、云的统一调度，实现“一网联多云”“一键网调云”。

虽然算力网络当前已经初步具备了应用落地的条件，但是产业界也应清楚认识到目前尚未突破的一些核心技术难点，即算力网络持续健康发展面临的若干关键技术问题，本文将探讨这些问题。

1 算力度量与算力建模

算力度量和算力建模是算力网络底层的技术基石，如何在网络中有效地对算力进行标识和度量是算网融合发展的第一步。不同于传统的硬件计算资源度量，算网融合过程中算力的度量不仅依赖中央处理器（central processing unit，CPU）、图形处理器（graphics processing unit，GPU）等处理单元以及内存、硬件等存储资源，还与业务类型、节点的通信能力等息息相关，可以说作为算网融合发展的基础，如何构建统一的算力资源模型及算力需求模型、实现算力的一致化表达是算力度量与算力建模的关键问题。

目前，算力资源的度量和建模方面的研究进展相比算力网络其他研究方向稍显缓慢，经过分析，主要原因包括以下几点。

（1）衡量计算能力的 CPU、GPU、神经网络处理器（neural network processor unit，NPU）等异构处理单元很难进行标准化的统一，目前仅有中国联通和中国移动在 CCSA 的标准研究报告中提出根据整数运算速率、浮点数运算速率等不同运算类型的维度衡量处理单元计算能力的方案，但是在此方案中，很难直接比较不同的运算类型。

（2）算力资源除了计算单元，还包括内存、存储、通信能力等其他资源，如何将所有不同类型的资源进行标准化统一建模，并供上层资源消费者使用，目前还没有学术界和产业界都比较认可的标准。

（3）上层应用对算力资源的类型和需求量往往差异很大，一般只能通过经验数据来描述某一特定场景下的算力资源需求，这也是导致异构算力资源完成统一及标准化的一个难点所在。目前，产业界提出了算力交易平台的初步解决方案：构建算力资源池度量模型，例如，一个算力资源池中包括8核vCPU、8 GB内存、100 GB硬盘，调用此算力资源池的通信带宽为100 MB 等，用户在算力交易平台中以已建模的算力资源池为使用单位来对算力资源进行使用。

综上所述，“底层算力资源度量的标准化统一”以及“上层应用对底层算力资源需求的标准化统一”是算力度量与算力建模需要解决的两大问题。

国内某运营商在其研究报告中提到了三级算力度量指标体系：异构硬件算力度量、节点服务能力度量、业务的支撑能力度量。这个三级指标体系初步提出了将某种业务需求与节点服务能力映射的思想，再通过节点服务能力与算力资源的映射关系，最终形成业务的算力需求与算力资源映射的关系。这种算力度量指标体系为算力度量和算力建模的目的提供了明确的方向。未来的算力网络业务需求与底层的算力资源自动匹配，需要能够将业务需求尽可能精细化地拆分为原子业务需求，拆分的颗粒度为一个原子业务需求能够尽可能精确地与一个或者一组可以明确量化的算力资源相匹配。例如，假设定义“在1 ms内完成1 MB视频图像的3D渲染处理”为一个原子业务，那么恰好能够完成该原子业务处理的算力资源为本地的1个vGPU和10 MB内存，这就能够将原子业务与其需要的算力资源相匹配，从而整体的业务需求就能够相应地与其总体算力资源需求相匹配。更复杂的是，算力资源的需求还可能与网络资源的带宽以及用户和算力资源的距离有关，这就需要设计更复杂的算力度量和算力建模模型，与上层的业务需求进行匹配。

2 基于算力信息的路由决策

在算力网络中，将用户业务流量调度到合适的算力资源池中进行处理，需要网络具备精确的路由决策能力，能够基于算力信息进行路由计算。传统路由计算是基于链路的基础度量值进行选路的，其在网络发展的初期具有简单易度量的优点，适合早期互联网业务应用类型不多情况下的网络发展，但是，随着互联网业务类型的飞速增加，传统的路由计算方式对于特定的业务需求已经无法保证最优的路径调度。基于传统路由计算方式的选路机制如图1 所示，在虚拟现实（virtual reality，VR）场景中，在传统网络的路由决策指导下，用户选择了链路距离最近的多接入边缘计算（multi-access edge computing，MEC）云中的某个服务器（server），但是显而易见，对于新型的VR视频业务处理，GPU是更好的选择，所以如果在网络中还是采用基于传统链路度量值的选路策略，资源无法得到最好的利用。

为解决上述的问题，产业界提出了计算优先网络（computing first network，CFN）机制，CFN在链路开销的基础上增加了多种算力和网络信息的度量方式，如CPU、GPU、现场可编程门阵列（field programmable gate array，FPGA）和带宽、时延等。同时，CFN 结合任播技术还能够以“边-边协同”的方式实现算力资源的智能管控，完成应用部署的负载分担。

这里仍旧以VR视频业务为例，在此场景中， VR视频信息需要发送到MEC上进行处理，各个MEC 上都具备视频信息处理的能力，路由器（router）1中的算力资源信息见表1。其中，算力的单位为每秒运行的浮点计算吉次数（giga floating-point operations per second，GFLOPS），G表示10亿。由于各MEC都具备视频处理能力，所以通过任播地址，理论上可以将视频数据流发送到任何一个MEC进行处理。但是，从表1可以看出，MEC1和MEC3不具备GPU处理能力，基于算力资源的CFN选路机制如图2所示，视频信息数据流没有选择MEC1和MEC3，而对于具备GPU处理能力的MEC2、MEC4和MEC5，在具备相同处理能力的前提下，Router1到MEC4的网络时延最低，所以 MEC4 是最优的选择。再者，为了视频信息并行处理的效率，Router1 选择将视频数据流同时发往MEC2、MEC4和MEC5，实现了视频业务处理的负载分担。

如上所述，基于CFN的路由决策机制在传统路由决策的基础上考虑了算力信息的权重，在算力资源多样性的网络中，能够精确地完成流量调度，打破了传统路由决策机制的局限性，使得业务调度能够根据自身的特点选择合适的处理设备，并能够做到资源的充分利用，但是在实际的应用中，由于算力资源的多样性和网络的复杂性， CFN还存在以下尚未完全解决的问题。

（1）算力信息及网络信息指标多样化，目前的算法还无法精确包含所有影响路由决策的信息，只能在特定的场景中针对特定的需求进行路由算法的定制化设计。

（2）随着网络规模的扩大，网络中链路故障、设备端口震荡、网络拥塞等问题时刻在出现，这些故障会导致算力信息和网络信息指标权重的变化。算力资源的指标权重比传统单一的链路开销权重个数要多得多，所以网络变化对基于算力资源的路由计算影响就会非常严重。针对此类网络变化导致的影响问题，可以给路由计算设置抑制时间或者触发路由计算的门限值，以降低频繁的路由变化给业务处理带来的不利影响。例如，在1 min 之内，如果资源信息变化非常频繁，则只进行一次路由计算；或者当资源信息的变化在1%以内，则不触发路由计算。

（3）CFN机制需要通过在传统的路由协议上进行扩展用以携带算力信息和网络信息，而传统的内部网关协议（interior gateway protocol，IGP）和外部网关协议（border gateway protocol，BGP）路由协议设计无法实现端到端信息的传递，这导致跨域的路径选择还不能做到非常精确，这对广域网上算力路由决策的准确性提出了很大的挑战。

针对上述 3 个问题，基于产业界目前对算力网络的研究进展，本文给出如下解决思路。

（1）算力资源的指标多样化使得路由计算算法的复杂化问题难以解决，这就需要通过算力度量和算力建模技术将算力资源的指标尽可能归一化，通过减少指标参数的方法降低算法的复杂度。

（2）网络的变化带来的算力信息权重的频繁变化是路由计算无法接受的，但是为了路径选择的准确性，路由计算又需要实时对网络环境作出响应，那么在算力网络的路由决策机制设计中，就必须在降低网络变化频繁性的影响和提高路径选择的准确性之间进行折中，或者采取全新的路由决策方案及提高网络的容错能力。

（3）要实现广域网中大规模算力网络的运行，还必须解决算力信息和网络信息的跨域传递问题，打破传统路由协议的限制，目前比较流行的IPv6分段路由（IPv6 segment routing version 6， SRv6）协议能够在一定程度上实现端到端的信息打通。

3 云-边-端的算力协同

随着全球数据总量的快速增长，数据处理对算力的需求陡增，而由于工艺的约束，单芯片的算力在5 nm之后也将接近顶峰，传统集约化的数据中心算力和智能终端的算力可增长空间也面临极大挑战，这决定了未来算力的发展不能仅仅依靠于单点计算能力的提升，更需要对分散算力进行集中使用。算力网络的愿景之一就是将全网中的云-边-端算力进行统一纳管、按需调度，实现云-边-端的算力协同。

中国联通研究院最早在2019年10月发布的《算力网络白皮书》提出了云-边-端的三级算力架构，并指出算力网络是实现云-边-端算力高效利用的有效手段。发展至今，算力网络也通过其精准的调度、灵活的连接、充分的协同，一定程度上实现了专业、弹性、协作的高效云-边-端算力整合，但是基于当前算力的分散性和动态性的特点，云-边-端的算力协同还存在一些尚未完全解决的问题，如下为对其中一些问题的分析，并提出了相应的解决思路。

（1）云-边-端算力的海量接入问题

云-边-端的算力，尤其是端侧的算力，在网络中分散的范围非常之广，如何建立一个如此庞大、能够“海纳百川”的统一算力管理系统，首先需要解决的问题是在海量的算力接入情况下，如何保证系统能够保持足够的稳定性，并能够及时完成算力的整理和归类，以供业务应用进行使用。在目前的解决方案中，层级化的架构体系是一个较好选择，通过划分区域范围，使算力管理系统在保证自身处理性能的前提下尽可能多得容纳算力节点，下级系统接入上级系统，上级系统负责下级系统的统一管理。

（2）算力的动态使用问题

每一个接入算力管理系统的云-边-端算力节点，可能需要同时满足本地算力使用和远端算力使用，那么就会出现本地可用算力和网络可用算力一直处于动态变化中的情况，如何确保业务应用使用远端算力的准确性，是算力管理系统需要考虑的问题。例如，对于变化不太频繁的算力节点，可以通过资源独占锁定的方式防止其他应用的调用，而对于变化过于频繁的算力节点，可以设定一个是否将节点纳入统一管理的门限或者从该算力节点中单独划分出一部分资源专门供系统统一管理。

（3）算力的调用粒度问题

在目前的算力网络系统中，能够实现以一个业务应用为单位、将报文调度到某个资源池中进行处理，或者通过编排系统实现负载分担。但是，在系统调度功能中，即使实现了负载分担功能，也是将同一个业务应用的不同会话调度到不同的资源池中进行处理，还没有真正实现细分到任务或者进程颗粒度的算力协同。例如，不同资源池能够为同一个业务应用提供不同类型的算力，或者系统能够将业务应用拆分为不同的服务或者进程分发到不同的资源池中进行处理。为了能够达到上述的服务调用粒度，一方面，系统需要具备将业务应用拆分到足够颗粒度的子服务的能力，使子服务的处理资源需求能够恰好匹配资源池中的算力资源；另一方面，系统还应具备将业务应用根据所需要的算力资源类型进行子服务拆分的能力，使得特定的子服务被特定的算力资源处理，从而提高处理效率。例如，算力网络的子服务拆分调度解决方案如图3所示，服务App1能够被拆分为3个子服务（App1.1、App1.2和App1.3），并根据子服务自身的资源需求，通过算力网络调度到相应的算力资源中进行处理。

4 基于服务的云网融合

在未来的互联网中，用户只需要通过终端接入网络，提出业务需求，算力网络就会根据用户的需求自动在网络中搜寻服务提供节点，用户根本无须关注服务提供节点的真实物理位置，所有合理匹配算力资源的工作都由算力网络完成，真正实现了基于服务的云网融合。但是，在当前的商用互联网中，网络和云的独立性大于融合性，由于近10年信息技术（information technology，IT）的发展领先于通信技术（communication technology，CT），网络已经逐步沦为云间的通信管道，作为网络通道提供者的运营商们为了使网络能够发挥更加智能的作用，精确地为用户提供服务等级协定（service level agreement，SLA）服务，正在逐步思考网络如何更好地发挥主导作用，以网络为中心，根据用户的需求智能化地调度云内服务。

算力网络可以看作云网融合发展的高级阶段，它为用户呈现的是一个完整的大规模资源池，用户只需要接入这个资源池，而不需要关注提供服务的资源池所在的物理位置。在这个大规模资源池中，云作为服务承载的节点，网作为服务间信息交互的纽带，如何让服务节点随着网络的延伸形成一个全连接的关系且尽可能地靠近用户以降低时延，并且网络路径能够随着承载服务的云的改变而动态变化，是云网融合需要解决的核心问题。本文结合目前云网融合的研究进展，提出以下3个思考方向。

（1）云网融合需要一个位于网络管控和云管控之上的总体编排管控系统（以下简称“编排系统”）来建立网和云之间的联系。当用户选择服务时，编排系统先要根据云资源是否可用，对服务及服务所处于的云进行选择，并在此基础上完成业务路径的编排，然后将编排后的业务路径下发给网络控制器，由网络控制器根据业务路径进行路由决策后下发路由表项指导网络设备进行数据报文的转发。

（2）云网融合的场景，可能涉及多次入云的情况（如业务链场景），传统的路由决策方式在复杂场景下逐渐显现出其弊端。例如，策略路由（policy based routing，PBR）的实现方式，虽然现有绝大多数网络设备都能够支持，不需要对设备本身的功能进行修改，但是配置复杂、可扩展性差，无法适应未来云网深层次融合的网络。虽然网络服务报文头（network service header， NSH）的实现方案已经非常成熟，但是它需要进行数据面的修改以支持 NSH 的转发，并且在入云的服务功能转发器（service function forwarder， SFF）上需要维护每个业务链的转发状态，在业务部署时需要在多个网络节点上进行配置，控制平面复杂程度相对较高。基于SRv6的业务链，只需要在头节点显式指定报文的转发路径，实现方式灵活，不需要在网络的中间节点维护逐流的转发状态，部署也相对简单，此实现方式目前的瓶颈主要在于非感知（unaware）模式的云网互联配置复杂度和感知（aware）模式的服务支持能力（非感知模式和感知模式的区别在于云内服务是否支持 SRv6 协议），这可以通过产品落地推动。

（3）网络管辖权问题。云网融合场景涉及的入云问题，在网络路径中不仅包含接入网及承载网络上的路径问题，还包含“最后一公里”的云网互联及云内网络问题，这些问题主要体现在网络设备的管辖权上。从网络路径规划的角度上看，网络节点被一个控制器统一管理的效率最高，但是在现网实际应用中，网络控制器只能对云外的网络设备进行管理，而且在云外网络中不同的管理域也需要不同的网络控制器分别进行管理，而对于云内的网络，其管理权一般属于数据中心内的网络控制器和云管控系统。为了在算力网络中创建一个云网深度融合的系统，目前产业界正在尝试通过上层的编排系统进行统一的协同调度，或者通过算网融合设备的创新方式减轻这种复杂的网络管理问题。

5 算力网络信息安全

整个算力网络自下而上包括物理设施、软件系统、网络架构、系统平台及应用服务等功能组件，为确保整个算力网络体系的安全可靠，需要在物理安全防护、系统安全加固、网络访问控制、应用安全防护以及安全管理等方面进行安全保障。

一方面，在算力网络体系中，需要解决软、硬件系统加入算力网络的可信任问题以及算力网络使用者的权限管理问题等，这可以通过传统的鉴权管理系统方案解决，鉴权管理系统对算力网络的管理权限和算力资源的使用权限进行合理的安全管理，以确保算力网络的安全运行以及算力资源的合法使用，鉴权管理系统解决方案示意图。

另一方面，从网络架构的角度考虑，网络虚拟化、网络切片以及异构接入均带来新的潜在安全问题。随着NFV的引入，弹性、虚拟化的网络使安全边界变得模糊，安全策略难以随网络调整而实时、动态迁移，虚拟机容易受到归属于同一主机的其他虚拟机的攻击，而传统的基于物理安全边界的防护机制在云计算的环境中难以得到有效的应用。要对如此大规模且边界模糊的网络采取针对性的安全方案，给安全系统提出了巨大的挑战，针对此情况，建议使网络中的软/硬件系统既作为安全方案的受益者，也作为方案样本的提供者参与整个安全体系的建设，这可以通过云安全平台的方案共享实现。

云安全平台通过构建分布式平台的方式同步算力网络的安全解决方案，其核心思想是构建一个分布式管理和学习平台，以大规模用户协同的方式计算防护网络中的病毒及木马，云安全平台解决方案如图5 所示。云安全平台体现了一种网格思想，每个加入系统的设备或应用既是服务的对象，也是完成分布式管理功能的一个信息点。

6 结束语

综上所述，标准化的算力度量与建模是完成算力路由决策的前提，是实现算力网络进一步发展的基础。通过算力网络对算力的精确调度，整合全网的算力，从而实现云-边-端算力的协同，并在算力服务化的基础上，完成基于服务的云网融合，同时，在网络信息安全技术的保障下，实现算力网络系统的健康运行。

当前，算力网络的发展目前已经从理论分析阶段逐步发展到试点实践阶段，在取得成绩的同时也隐含了诸多亟待解决的技术问题。本文从算力度量与算力建模、基于算力信息的路由决策、云-边-端算力协同、基于服务的云网融合及算力网络信息安全5个方面，分析了算力网络建设中可能会遇到的一些实际问题，并提出了初步的解决方案，希望抛砖引玉，和业界同仁一起逐步完善算力网络系统建设，共同促进算力网络的持续健康发展。