摘要

  • RFC 9938 是 IETF Informational 文档，汇集了 DetNet 控制器平面的概念、要求和架构选项，并明说具体协议方案留待后续文档。
  • 控制器收到流请求、算出显式路径或发出配置，并不能单独证明每一跳已经接纳并持续保留资源、PREOF 已对目标流运行、性能边界已被测得，或业务后果已经成立。

一块大屏幕最容易制造一种错觉：控制器看到了拓扑，读取了节点能力，接到了 API 请求，给出了路径，又显示配置完成；于是，服务似乎已经被证明。实际上，屏幕把计划、指令和结果挤进了同一条绿色时间线。

RFC 9938 在 2026 年 3 月以 Informational 形式发布，题为 A Framework for the Deterministic Networking (DetNet) Controller Plane。摘要称它提供框架概览，讨论的概念和要求可以成为未来解决方案规范的基础。引言进一步说明：它不提供控制器平面解决方案的协议细节，这些解决方案将由后续文档处理。

这并非保守措辞，而是正确的边界。框架的价值在于把尚待实现和核验的接缝画出来：应当收集哪些事实、如何接收请求、如何算路、怎样预留、配置与监测什么。框架不能替代某一网络、某一时刻、某一服务已经成立的回执。

三种架构都不能替代每一跳的事实

RFC 9938 给出三类架构：使用动态信令的完全分布式控制、类似 SDN 的完全中心化控制，以及二者结合的混合控制。中心化示例中，控制器收集节点拓扑与 DetNet 能力，从 UNI、API 或北向接口得到流建立请求，再借助 NETCONF/YANG、DetNet YANG 或基于 PCE 的控制器配置节点。分布式模式让网络配置资料经由信令协议传播；混合模式让控制器与协议协作。

它们是可能的资料交换方式，不是一个已被统一部署的答案。RFC 9938 对混合模式还明确指出：各种情况下所需的协议扩展属于未来工作。

因此，必须给每一句运行描述限定事实范围。“控制器接到请求”证明输入到了控制点；“控制器计算出路径”证明它依据当时的资料和规则得出了候选；“下发了配置”证明它试图施加指令。三者都有价值，但都不等于所有相关节点接纳了状态、队列和资源在服务周期内仍然有效、保护图已经形成，或目标数据流正处于承诺的界限之内。

要求清单恰好说明了回执还缺什么

RFC 9938 要求支持 DetNet 流的动态创建、修改和删除。可能涉及显式路径确定、链路带宽、缓冲及其他资源预留、排队纪律、双向流处理和聚合。它也要求支撑包复制、消除和排序功能 PREOF。

这些是一个解决方案需要完成的任务，不是对某个服务已经完成的宣告。路径算出不等于资源准入；准入请求不等于在之后的拓扑或策略变化中仍被保持；设备有配置状态不等于相应转发和队列确实作用于这一流；多段路径也不等于复制、消除与排序已经为该流及其对应时间段正常执行。

跨域情形更加清楚。RFC 9938 说不同域的控制器平面功能必须协作，控制器可能需要彼此发现、认证并协商逐跳行为。另一个运营者的边界不是中心大屏上的空白，而是一段需要自身证据和授权的接口。

服务应有一串可回放的回执

先记录请求：服务和租户身份、获授权的提出者、两端、方向、流量规格和请求的边界。再记录控制器决定：拓扑和能力快照、算法与规则版本、候选路径及配置时期。然后记录准入：每个节点的确认、所分配的资源与队列、标签或封装状态、保护角色和到期/续期状态。测量记录要另列目标流量集合、方向、方法、时间源和窗口。最后的结果记录必须来自真正承担后果的服务边界。

这就是亨路“运行中代码优先”的实际应用：模型、控制器意图和集中视图不能凌驾于运营者可在运行系统内本地核验的状态。最低初始规范也要求共同层只说明必要且可验证的事实，而不是让编排层获得不可挑战的裁判地位。声明、计算、安装状态、测量和结果是不同的现实层。

Sources