DetNet 路径优化先要回答授权问题

Summary

RFC 9938 描述的 DetNet 控制器平面能够接收流请求、计算可行路径、选择所谓最优路径、预留资源并安装逐跳行为。但算法必须先获得一套经授权的排序：时延、丢包、抖动、带宽、保护、共同风险、多域承诺以及普通流量的生存空间，究竟谁优先。
应补充的不是一份敏感拓扑副本，而是“约束归属回执”：把请求及其版本化目标，与有权处理取舍的人、各域承诺的资源预算、计算所依据的状态、重新评估的触发条件、例外期限和资源释放负责人绑定起来，同时避免公开路径、时刻表和流量用途。

“最优”按钮隐藏了谁的偏好

在管理界面上，“计算最优路径”很容易被设计成一个按钮。按下以后，系统读取拓扑和能力，排除不满足条件的候选项，再把得分最高的一条呈现出来。这个过程看起来中立，因为每一步都能用数字解释。

真正具有分配后果的步骤，却发生在按钮被按下以前。

假设有两条路径都符合最大时延。第一条较短，但与一项已有的受保护业务共享故障风险；第二条需要额外缓存，并通过两条相互分离的支路复制数据。前者节省资源，后者增加连续性。究竟选择哪一条，不是图上某条边能够回答的问题。它取决于业务承诺、风险容忍、资源上限，以及谁被授权让其他流量少获得一部分机会。

算法可以忠实执行这些答案，却不能因为执行得精确，就自动证明答案合法。“最优”从来都是“相对于某个目标函数最优”。目标函数把什么视为硬性条件、什么视为偏好、谁有资格修改权重，这些都属于治理事实。

RFC 9938 恰好把这条边界展示得很清楚。该文档于 2026 年 3 月作为 IETF 的 Informational RFC 发布，为确定性网络控制器平面提供框架。它汇总概念和要求，说明分布式、集中式和混合式架构可能如何满足这些要求，并明确把具体解决方案协议留给后续工作。

因此，本文不是指责 RFC 少写了一条强制规定。框架不替每个运营组织规定授权制度是合理的。风险在于部署者后来把“接口接受了请求”误当成“请求所代表的取舍已经获得授权”。

控制器平面汇聚功能，不等于汇聚责任

DetNet 所说的 Controller Plane，把传统上常被分开的控制平面和管理平面纳入一个框架。前者负责实例化和维护流、分配并传播标签等信息、通过带内或带外信令支持功能；后者负责配置、故障与性能管理，并利用 OAM 检查服务状态。

RFC 9938 列出的能力范围很广：动态创建、修改和删除 DetNet 流；显式路径计算；链路带宽、节点缓存和处理资源预留；队列策略；双向流；聚合和解聚合；标签管理；复制、消除重复和重新排序；拓扑与能力通告；对网络变化作出适应；以及服务性能和连通性监控。

这些动作会改变共享网络的资源分布。它们不是把表单从一个系统抄到另一个系统。一个流得到确定性保护时，另一些流可用的带宽、缓存、排队机会或保护走廊可能减少。控制器在技术上能够执行，不等于控制器这个抽象角色在制度上拥有所有选择。

应用所有者知道用途，服务所有者承担承诺，Flow Management Entity 表达请求，Controller Plane Function 计算和下发行为，域运营者决定本地是否接纳，安全团队保护控制消息，运维人员解释测量结果。它们可以由同一组织甚至同一软件实现，也可能分属不同主体。架构上的合并不应抹去问责上的区分。

请求可以来自应用 API、静态配置、SDN 控制器或分布式信令。这些是传递意图的通道，不是优先级本身。

参数有数值，但未必有清楚的身份

RFC 9016 提供 DetNet 流和服务信息模型。请求可以描述带宽、最大端到端时延、时延变化、丢包和其他条件。RFC 9938 还指出，流量规范表达的是最坏情况而非平均情况，这对充分预留资源十分重要。

同一个数值可能来自完全不同的制度来源。最大时延也许由物理控制环决定，也许来自合同，也许只是工程团队为保险而设置的默认值。双路径保护可能是生命安全所必需，也可能沿用了一份过时模板。带宽峰值可能经过负载证据支持，也可能多年没有复核。

如果系统只保存数值而不保存性质，它就不知道这是硬约束、软偏好还是监测阈值。全部当成硬约束会制造不必要的拒绝；全部允许降级，则可能把服务保证掏空。把旧测量当成当前事实，还会让一个可完全复现的计算建立在已经失效的世界上。

YANG 可以表达期望状态，NETCONF 可以传送配置，PCE 可以计算集中控制路径，BGP-LS 可以提供拓扑与能力信息。它们各自解决真实问题，却不会凭语法推断出“谁有权写入这个值”。

控制器凭证也不能承担全部含义。身份认证可以证明消息来自某个已识别主体，授权策略可以允许该主体调用某类操作。但具体命令是否仍在授权范围内，还要看业务、资源上限、参与域、有效期、降级条件和例外期限。一个拥有全网配置能力的账户，并不当然拥有无限分配资源的委托。

预留资源就是分配稀缺性

RFC 8938 说明，DetNet 转发子层通过资源分配和显式路径提供所需服务。预留带宽、缓存和队列机会，可以减少争用、丢包和抖动。文档同时指出，“最佳”路径可能以最高带宽、最低抖动或多个指标为目标，不一定是最短路径。

这意味着网络里没有一条脱离目的而天然最佳的路线。指标的选取与权重必须先被确定。

PREOF 更能说明代价。为了抵御链路或设备故障，数据包可以在多条不同路径上复制，并在后续节点消除重复和恢复顺序。保护提高了可靠性，却也在多条支路上占用传输、处理和缓存资源。给一个流增加保护，可能让另一个流无法获得同样等级。

RFC 8655 没有把 DetNet 描述成与普通网络完全隔离的王国。确定性流可以占用很高比例的带宽，但必须避免让非 DetNet 流量陷入饥饿；详细调度应为普通数据包留下足够机会。把流发送到未预先具备能力的下游网络，被视为故障，而“已配置能力”甚至可以包含一项行政决定：下游是否拥有足够容量。

这项行政决定就是治理接点。控制器需要一个数值或布尔结果来完成计算；审计需要知道谁做出该承诺、针对什么范围、有效到何时，以及哪类其他用户受到保护。

如果只检查请求业务的 SLA，算法可以在局部上完美、在整体上失当。它可能为一项低优先级服务占用共同风险较低的走廊，可能重复并不需要复制的数据，或可能把非 DetNet 流量压到机构政策所不允许的水平。

三种架构只是改变证据出现的位置

RFC 9938 描述分布式、完全集中式和混合式控制器平面。没有一种形式能够自动消除授权问题。

分布式模型里，入口节点和沿途节点依靠路由与信令信息完成路径和预留。本地接纳的组合可以形成端到端服务。优点是没有一个组件必须掌握全部敏感信息；困难是事后证据分散。审查者需要把初始请求、各节点或各域的接纳、版本和最终状态连接起来，而不能虚构一个从未存在的中央决定者。

集中式模型里，控制器可以汇总拓扑、计算候选路径，并配置所有沿途节点。技术时间线更容易还原，但权力也更容易被默认。一个广泛的控制器身份可能同时服务多个业务部门和优先级。它能配置所有设备，不等于每项请求都能使用同一资源额度。

混合式模型里，中央控制器可能负责计算和分发路径信息，RSVP-TE 等机制负责信令与资源预留。计算和信令可以分别成功，却依据不同版本的状态。计算时可用的链路在接纳时已经变化，本地策略可能调整预留。如果系统只保存“两个步骤都成功”，就无法证明安装的是最初被授权的那项选择。

架构决定哪些参与者产生哪类证据；治理决定这些证据如何共同说明一个完整授权。

多域协作不是一张无限额度的通行证

RFC 9938 的多域部分指出，多个 Controller Plane Function 可能需要协同，把 Flow Management Entity 的请求转化为每个流、每一跳的行为。不同域的控制器需要相互发现、认证并协商；应用平面也可能提前把责任拆分给各域。

相互认证可以防止陌生组件冒充控制器。这是必要条件，但只能证明对方与某个技术身份相连。它没有说明对方能请求多少带宽、能否延长保护、可否改变有效期，或者能否让本域承担另一类风险。

协商成功也只证明双方在某个消息范围内达成结果。如果两个域对时延测量窗口、共同风险、故障降级或资源释放的含义不同，局部成功仍可能拼不成端到端承诺。

更合适的证据是可组合的域承诺。每个域不必公开内部拓扑，只需对已接受的约束子集、资源类别、时间窗口、激活结果、重新评估条件和释放事件作出可验证声明。全局回执通过摘要把这些承诺与同一请求版本绑定。

这样既保留自治，也允许纠错。某个域撤回承诺时，端到端状态应进入重新决策，而不是静默换路。静默替换也许能维持传输，却可能破坏服务所有者视为硬条件的风险隔离、管辖边界或最大时延。

认证回答“你是谁”；承诺回答“你代表谁、答应了什么、范围多大、到什么时候”。

真实签名也可能保护一条越权命令

RFC 9055 解释了控制器安全为何重要。控制或信令消息被修改、注入，会操纵路径和资源分配。受控组件可能让网络节点误以为它有权发号施令。控制器平面欺骗可以改变带宽、增加或删除端点、丢弃流，甚至创建虚假流耗尽资源。延迟撤销还会造成资源泄漏，阻碍新流获准。

消息认证、完整性保护和抗单点失陷设计因此不可缺少。不过，它们不能代替具体委托。

设想一条命令的签名真实、证书有效、控制器也未受攻击。命令仍可能越权：资源超过业务上限，例外已经到期，额外域未获批准，或临时保护模式被永久化。更换密钥解决不了这种问题，因为身份没有错。重新调算法也不一定有用，因为算法可能完全忠实于输入。

需要检查的是命令与委托是否一致，而不是只检查命令与凭证是否一致。

另一方面，治理记录不能变成攻击者的侦察资料。RFC 9055 指出，流的数量、带宽、时间安排等信息会暴露业务意图。普通审查通常只需要摘要、时间、资源等级和合规结果，不需要完整路径、精确时刻表和工业用途。

测量决定旧选择何时失效

管理侧要监测性能和连通性。RFC 9938 特别区分主动与被动性能测量：主动方式注入测试数据，可能影响时延和吞吐，因此不建议作为运行域中的常规方法；被动观测更适合生产环境。RFC 9551 对 DetNet OAM 作了更系统的说明。

所以，一个指标必须带着方法、窗口和新鲜度。上线测试得到的数值不能无期限代表运行状态。被动平均值可能掩盖偶发的最大时延违规。拓扑快照可以在结构上完整，却对一次紧急重分配来说已经太旧。

每个依赖观测的约束都应绑定证据来源。保护路径依赖风险分离，就要监测分离关系是否变化；例外允许短期降低保护，就要在到期时触发新决定；流删除失败，就要把残留资源列为有负责人和修复期限的状态。

监控不是算法运行后的奖状。它决定何时必须重新取得授权并再次计算。

计算能够证明什么，不能证明什么

如果固定拓扑与能力快照、约束版本和算法版本，一个可复现计算能够证明：哪些候选被评估，哪些未满足条件，为什么某一条排名最高。安装证据能够说明哪些节点收到了状态。OAM 能够说明某个观察区间的运行表现。

这些证据本身不能证明：

请求者拥有定义业务目标的权力；
使用的约束仍是当前版本；
硬条件与软偏好没有被混淆；
路径消耗低于批准的资源上限；
复制和额外缓存确有授权依据；
普通流量的最低机会仍受保护；
各域接受的是同一个端到端含义；
降级例外具有负责人和到期时间；
委托结束后资源已经释放。

这不是计算能力不足，而是证明对象不同。把两者混为一谈，只会让缺失的制度事实更难发现。

一份不泄露拓扑的“约束归属回执”

回执可以从请求摘要开始，保存请求者角色、服务所有者、Flow Management Entity 边界和有效期，而不复制敏感业务载荷。然后绑定一份版本化约束集合。

每项约束需要记录来源和性质：硬约束、软偏好或监测触发。要区分预留峰值与观测平均值、合同上限与工程目标、强制分离与希望分离。还要记录保护非 DetNet 流量的底线，以及业务能使用的最高资源等级。

决定权必须明确：谁可以排列软约束，谁能批准超出日常额度，谁能接受降级，谁能引入新域，谁能下令撤销。不能仅凭一个全局管理员账号推定这些权力。

计算证据可以使用摘要和版本：拓扑能力快照及新鲜度、评估器版本、候选集合摘要、选中路径摘要、排除原因和剩余不确定性。各域只追加本地承诺令牌，无需公开内部路由。

最后记录生命周期：激活结果、OAM 窗口、重新评估触发、例外到期、回退目标、释放负责人和纠正状态。事实变化时，新回执显式引用并取代旧回执，而不是覆盖历史，假装旧决定当时已经知道后来发生的事情。

证据边界

这些 RFC 没有证明任何具名网络发生了故障、控制器做了不当分配、运营者违反了承诺，也没有提供采用率、容量短缺率或攻击频率。RFC 9938 是 Informational 框架，不是已经完成的统一控制器协议。

“约束归属回执”同样不是 IETF 要求。它是 Daniel Kade 针对一个治理断点提出的分析：机器越能精确执行组织的取舍，组织越需要保留谁有权规定这些取舍。

路径计算、控制器认证、配置下发和 OAM 都应继续加强。但在把结果称为最优以前，先留下一个可以复核的答案：它依据谁的约束，花费谁的资源，有效到什么时候。

DetNet 的“最优路径”首先是治理决定，其次才是计算结果

为何重要