摘要

  • IETF新发布的RFC 10066为PCEP增加多路径信令，同一LSP可容纳多条路径及其可选权重；此前SR Policy候选路径的PCEP信令只容纳一个段列表。
  • PCE计算的正向路径数不得超过自己与头端PCC有效能力值中的较小者；头端收到超量路径，必须返回明确的协议错误。

多路径最容易在控制器的屏幕上显得便宜：再画几根线就好。真正付账的是入口路由器。它要保存每条路径的状态，把流量送上不同的段列表，还要在权重变化时处理流量重排。RFC 10066于2026年10月作为IETF拟议标准发布，补上了PCEP此前只能给一个SR候选路径传一个段列表的缺口，也给“能算”和“能装”划了线。

新对象PATH-ATTRIB放在每条显式或已记录路径之前，给路径编号，还可携带权重。不写权重就按1处理；权重为0的段列表可保留指令而停止承载流量；全部为0则候选路径无效。权重3比1代表预期的流分配比例，不是实测字节占比。采购会上出现“75%流量”时，先问它是配置值还是测量值。

能力边界由MULTIPATH-CAP协商。PCE报出可计算的正向路径数，PCC报出能在转发面安装的数量。双方会话先协商支持，单个LSP再可覆盖会话默认值。PCE只能采用两个有效上限中较小的一个。数值0表示无限制；RFC安全章节建议运营者设置非零上限，因为故障或被控制的PCE可以借多路径扇出放大头端状态。

协议拒绝并非礼貌提示。头端收到超过自己声明数量的正向路径，必须返回PCErr类型19、值36；没有成功协商就收到PATH-ATTRIB，则返回类型10、值45。反过来，PCE接到PCC上报的现存路径，即使条数超过自己的计算能力，也不能因此丢弃状态报告。现状记录不是一张新的计算订单；把它拒掉，控制器反而看不见现场。

RFC也明确列出代价：消息会更长，每个LSP的状态会更多；路径之间的MTU、时延和带宽可以不同。调整权重可能重新分配流，扰动拥塞控制并迫使路径MTU发现重做。运营者应能查看协商上限、路径ID、权重、反向路径关联和错误记录。标准给了字段，没有给出某家设备的部署数量或性能收益。下一项有用证据，是控制器与头端在负载下交换这些记录时的可见轨迹。

来源