6G基于 Dyncast 的算力网络架构
Posted 从善若水
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了6G基于 Dyncast 的算力网络架构相关的知识，希望对你有一定的参考价值。
本人就职于国际知名终端厂商，负责modem芯片研发。
在5G早期负责终端数据业务层、核心网相关的开发工作，目前牵头6G算力网络技术标准研究。
博客内容主要围绕：
5G/6G协议讲解
算力网络讲解（云计算，边缘计算，端计算）
高级C语言讲解
Rust语言讲解
文章目录
基于 Dyncast 的算力网络架构
当前的边缘计算部署还存在以下问题：
- 无法感知服务的算力资源信息；
- 相对静态的边缘节点选择，例如，选择最近的节点或者服务资源最多的节点等；
- 网络和算力分离，例如，我们将一个服务分配到最近的边缘节点，但是此时网络发生了拥塞，导致服务产生延时。如果在分配之初就能将网络路径的问题考虑进来，就可以分配到稍远且能满足需求的边缘节点上。
一种基于 Dyncast（Dynamic Anycast）的架构被提出使得任务能够被调度到 “最佳” 的边缘服务节点，这种架构在调度任务的时候会同时考虑网络状态和算力资源。
一、术语定义
CFN：Compute First Networking（算力网络）
SID： Service ID，表示服务的任播IP地址，客户使用它来访问该服务。SID与提供服务的实例没有什么关系。通常多个服务实例来为一个服务提供服务。
BID：Binding ID，SID中的某个实例的IP地址。一个服务可以由多个具有不同BID的服务实例来提供服务。
二、CFN-Dyncast 架构
服务实例可以托管在边缘数据中心的服务器、虚拟机、接入路由器或网关上。CFN节点是一种粘合剂，除了能够一致地向这些实例转发业务流，CFN- dyncast网络还可以交换附加到这些服务实例的计算资源信息。
上图就是 CFN-Dyncast 的架构，
- CFN：通常情况部署在运营商接入网的边缘侧。CFN将来自用户的业务流连续不断的转发到服务实例上。服务实例可以在不同的边缘节点上被实例化，同时每个边缘节点上还会运行一个 CFN node。一个服务可以有大量的实例且运行在不同的 CFN node 上；
- SID：用来独一无二的标识一个服务。同时也会标识这个特定服务下的所有服务实例（无论这些服务实例运行在哪里）；
- service instance：几个服务实例可以运行在同一个CFN node上（如上图👆），同样几个服务实例可以运行在不同的CFN node上（如上图👆）。每一个服务实例通过 BID 标识其运行在哪个 CFN node上。SID 和 BIDs之前是动态绑定的，它们之间的绑定包含了丰富的消息，例如，网络状态信息、可用资源信息等。提供这些信息的目的是为了CFN node可以根据这些信息选择出 “最佳” 的服务实例来处理这个服务请求。
当客户端发送服务请求时，它将被发送到附着在 CFN node 的上的 “最佳” 的服务实例。一个服务请求通常是数据流的第一个包。当 CFN Node 决定了哪个实例是这个服务的 “ 最佳” 节点后，所有属于这个流的数据包都必须经过相同的服务实例来处理。
三、架构组件和交互
上图的 Figure 1 中已经展示了这个架构的组件，包括，服务实例、CFN node、CFN dispatcher 和 客户端。下面详解介绍这些组件之间是怎么交互的。
3.1 服务标识和绑定
服务标识符(SID)是一种任播服务标识符(可以是也可以不是一个可路由的IP地址)，使用它来访问某一个特定的服务，而不需要关心具体哪个服务实例最终来处理这个客户请求。CFN node 必须能够知道 SID(及其绑定关系)，并且必须能够识别哪个流需要哪个服务。这可以通过不同的方式实现，例如，使用一个特殊范围或编码的任播 IP 地址作为 SID，或者使用 DNS。
BID 是一个单播IP地址。它通常是一个服务实例的IP地址。BID和SID之间的映射关闭是动态变化的，取决于服务请求生成时，当前的网络状态和可用资源情况。CFN node 必须保证业务流的亲和性，也就是说同一个业务流的数据包必须转发给同一个服务实例。
Figure 2 中给出一个使用SIDs和BIDs例子。这里有三个服务，分别是SID1、SID2和SID3。SID2有两个服务实例且实例化在不同的CFN nodes（CFN node2和CFN node3），完整的SIDs和BIDs绑定关系如下：
- SID1：BID21；
- SID2：BID22，BID32；
- SID3：BID33。
3.2 服务实例和CFN Node之间的服务通知
当一个新的服务实例被实例化、销毁或者性能指标发生变化（例如，负载），这个服务实例需要向其附着的CFN Node 通知其BID和SID之间的映射关系。例如Figure 3。
在CFN Dyncast 架构中算力资源信息是一个关键的信息。这其中像CPU、GPU等的算力能力是相对静态的，不会发生变化。而像CPU、GPU等的使用率、绑定的会话数量、请求队列的数量等是动态变化的。服务侧需要向其归属的CFN Node通知和更新这些信息，实现这种通知和更新的方式很多，例如，可以通过标准的协议或者使用管理系统的API等方式。
3.3 CFN Dyncast 控制平面
CFN Dyncast 需要一个控制平面来共享这些资源和成本信息。CFN Node 通过控制平面共享和更新其管理的这些服务实例的服务信息和计算成本信息。CFN Node 作为一个网络节点，其同样会检测到其它CFN Node 的网络状态。通过这种方式，每个CFN Node能够将这些信息聚合并形成一张包含可用资源和到达各Node成本的完整视图。例如，对于Figure 3 中的场景，不同的CFN Node 将得知存在两个SID2的服务实例，每一个服务实例都有一定的计算能力。在更新这种状态时可以有不同的机制，例如，IGP、BGP。
CFN Dyncast 提出的一个重要问题是，如何采取不同的方式表示计算指标。单个数字值计算的加权属性，如CPU/GPU消耗和/或关联的会话数可能是最简单的。然而,它不能准确反映感兴趣的计算资源。多维度变量可以提供更精确的信息，但是结构和算法的处理必须通用，以适应不同类型的服务。
👆这一部分其实就是我们之前的博客中提及的 “算力度量” 的问题
第二个重要的问题是系统的稳定性和信令开销。由于计算指标的变化非常频繁，故需要确定何时以及以何种频率在这些CFN Nodes 之间交换此类信息。这里有一系列的方法可以使用，例如，基于某个时间间隔更新，阈值更新，基于策略更新等。
3.4 服务需求的分发
假设算力度量已经被定义好并且设置了合适的更新速率。CFN Dyncast 数据平面具有将流分派到 “最佳” 服务实例的任务。当有新的流量到达CFN入口时，CFN Node会根据网络状态和计算资源选择最合适的CFN出口，并保证流的亲和性（同一个流的数据包发送给相同的服务实例）。
流量亲和性是 CFN Dyncast 应该具备的关键特性之一。流亲和性是指来自同一服务的流的数据包应该总是被发送到同一个CFN出口，由相同的服务实例来处理。
当一个新流来的时候，确定了最佳的服务实例和CFN出口后，会将流标识符、选择的CFN Node、亲和性超时时间等信息更新到流绑定表（Flow Binding Table）中。之后所有的数据包都会根据这个流绑定表进行转发。Figure 4 中展示了一个CFN 入口的流绑定表，
可以使用五元组来标识一个流绑定表中的一个表项。然而，值得注意的是不同服务可能具有不同粒度的流标识。例如，一个RTP视频流可能会为视频和音频使用不同的端口号，如果使用五元组，它可以被标识为两个流。然而，它们应该被标识为相同的流。因此，基于三元组的流标识符更适合这种情况。因此，希望在识别流时提供一定程度的灵活性，以便应用流亲和性。
流程亲和性属性信息可以根据业务提前配置。对于每个服务，信息可以包括流标识符类型、亲和性超时值等。流标识符类型可以指示这些值都是什么，例如，五元组、三元组或其它任何可以用作流标识符的值。因为我们处理单一服务时，匹配规则必须是分离的，这意味着两个不同的服务不需要不重叠匹配流集。
👆这里提到的就是之前博客提及的 “算力标识”
3.5 CFN 调度员
当CFN Node维护流绑定表时，内存消耗是由CFN入口节点处理的流数决定的。入口节点可以是边缘数据中心网关，因此它可以覆盖数十万用户，且每个用户可能有数十个流。CFN入口节点的流绑定表上的内存空间消耗可能是一个问题。为了解决这个问题，一个名为CFN Dispatcher的功能性实体可以提供帮助。
CFN Dispatcher部署在离客户端较近的位置，通常仅处理有限数量的客户端的流。在这种情况下，流绑定表所需的内存空间将会小得多。CFN Dispatcher 是一个位于客户端的实体，它将业务流引导到CFN出口节点。它本身不是一个CFN Node，也就是说，它不参与CFN Nodes 之间的网络状态和算力指标（computing metrics）的更新。CFN调度程序不能自行决定转发新流的最佳CFN出口。它必须从一个CFN Node学习这些信息，并对其进行维护，以确保后续包的流亲和性。通过这种方式，CFN节点只需为新流选择最合适的出口，并以显式或隐式的方式通知CFN调度程序。这样就免除了流绑定表的维护。
上图👆展示了CFN调度器和CFN Node之间的交互。CFN Node完成业务需求调度后，会向CFN调度器通知为该流所选的CFN出口节点。之后CFN调度器会维护流绑定表，以保证流的亲和性。CFN调度器和与其相关的CFN Node之间的消息交互需要被定义。CFN调度器可以简单地将流的第一个数据包转发给CFN Node，CFN Node决定使用哪个服务实例，并将该信息推送到CFN调度器的流绑定表中。然而，如果出现故障，例如CFN出口无法到达，则需要CFN调度器和CFN Node之间进一步交互。
四、CFN Dyncast 架构的关键点总结
4.1 CFN 控制平面
- SID：CFN Node必须通过相应SID的存在来感知现有服务。它可以通过不同的方式实现。如使用特定范围或编码的任播IP地址作为业务标识，或使用DNS；
- BID绑定：一组提供相同服务的服务实例被绑定到一个SID上。与这些BID相关联的还有一组描述实例状态的度量。这些绑定必须在CFN节点之间共享，这样它们才能知道不同的实例及其计算资源状态；
- 网络状态：CFN节点必须能够共享网络状态，使调度器在分发任务的时候可以参考网络的状态（例如，避免调度到有网络拥塞的路径上）；
- 算力指标和网络状态更新需要足够稀疏，以限制信号开销和保持系统稳定，但也需要足够有规律，使系统能够对突然的业务波动作出反应。
4.2 CFN 数据平面
- 对于新的数据流：CFN入口节点根据网络状态和归属的服务实例的计算资源，选择最合适的CFN出口；
- 流的亲和性：CFN的入口节点确保现有流的后续报文始终下发到同一个CFN的出口节点，以便由同一个服务实例提供服务。
五、总结
本博客介绍了CFN Dyncast的一种架构，可以将业务需求请求发送到最优的边缘，以提高系统整体的负载均衡。该算法能够动态适应计算资源消耗和网络状态变化，避免单边过载。CFN-Dyncast是一种基于网络的体系结构，它支持大量的边缘，并且独立于驻留在边缘上的应用程序或服务。
这里是从善若水的博客，感谢您的阅读📕📕📕
以上是关于6G基于 Dyncast 的算力网络架构的主要内容，如果未能解决你的问题，请参考以下文章