摘要

  • RFC 10066 允许 PCEP 在一条 LSP 下描述多条转发路径。计算端与接收端先声明各自可处理的多路径数量，计算时取较低的有效上限。
  • 节点可以拒绝超额方案，也可以向控制器报告比其计算能力更多的现存路径。某条路径还可以保留转发指令、把权重降到零来排空流量。提议、拒绝与运行状态需要分别留痕。

控制器画得下，设备装不下

在屏幕上多画几条路，鼠标不会抗议；承载它们的设备有上限。2026 年 10 月发布的 RFC 10066为 PCEP 增加了在一条标签交换路径下传递多条转发路径的办法。对于段路由策略，一条候选路径终于能携带多份段列表。SR Policy 架构早就容纳这种结构，RFC 9862却把同一候选路径内的多段列表信令留在范围之外。路线图先画好了，传输整张图的信封后来才到。

新信封附着容量限制。路径计算元素 PCE 与路径计算客户端 PCC 要先协商多路径能力和可处理的最大数量。PCE 回传计算结果时，不能超过双方有效上限中较小的那个。若送来的路径数超过 PCC 声明的能力，PCC 应以 PCErr 类型 19、值 36 拒绝。控制器负责提出方案，真正要安装方案的节点有权说明自己的容量。

上限可在会话层声明，也可针对某条 LSP 调整。双方若从未成功协商多路径能力，后来收到 PATH-ATTRIB 对象便是协议错误。这些规定让愿望与能力的冲突留在可读的交换记录里。运营者仍要核对声明的数字是否符合设备、软件、资源和本地政策。OPEN 报文里的容量是声明，不是转发表的验收报告。

反向报告有一处刻意的不对称。PCC 可能在 PCRpt 中报告比 PCE 自己能计算的数量更多的路径。RFC 10066 要求 PCE 把它当作运行状态，不当作越界请求报错。节点是在说「现在这里有什么」，并没有要求控制器再画这么多条路。拒收超过自身想象的事实，会让监控界面格外安静，也格外没用。

把权重调成零，路径还在

可选的 MULTIPATH-WEIGHT TLV 为每条路径携带一个 32 位无符号权重；没有该字段时默认是一。加权分流的比例由该路径权重相对于全部路径权重总和来决定。零最值得细看：在 SR Policy 中，它让相应段列表不再承载流量，同时保留转发指令；若所有路径都为零，候选路径按规则失效。路可以暂时封闭，图纸却不必撕掉。

维护时，删除路径、降为零权重、降低但不清零权重，以及故障导致路径消失，是四个不同事件，恢复方式也不同。只记「已启用多路径」，就把真正挪动流量的决定藏起来了。路径 ID、前后权重、安装状态和实际流量，才能说明哪条路为何沉默。标准定义如何传递意图；真实分流比例还要从运行中的转发数据里量。

RFC 10066 也把逐路径 METRIC 的编码留给未来扩展。现有 METRIC 可以描述整条 LSP，却不能替每份段列表交出相同的延迟与丢包记录。RFC 10067处理另一个问题：把两个单向段路由 LSP 关联起来，使两端知道反向路径。「一项服务」下面可能有多条路、两个方向、好几种不同的证据。控制台把它们压成一条绿线，看着舒心，信息却被压扁。

协议格式里藏着治理边界。PCE 提议，PCC 声明容量并报告现状，运营组织决定允许哪些变更、权重能移动哪些流量、怎样确认冗余真的工作。Heng Lu 的第 73 篇笔记把参与和授权分开。这里承担转发后果的运营者握有决策权，图画得最漂亮的组件不能替它签字。