摘要

  • RFC 9863 定义了 PCEP 对端如何声明颜色能力，以及如何在 LSP 对象中携带一个 32 位颜色属性。
  • 标签在协议层可被协商和校验；标签本身并不能证明服务选择、路径质量、控制权限或用户体验。

网络运营的语言常把“颜色”说得比它更有力量。RFC 9863 确实举了低时延 TE 隧道的例子，但它所标准化的核心只是一个无符号 32 位数值被放进 PCEP。这个数可以同一条 TE 隧道或 SR 策略关联，也可以在本地被赋予某种目标意义。它不是测量值，不是带宽预约，更不是服务已经走过该路径的收据。

协议首先约束的是能力和消息边界。PCE 或 PCC 通过 STATEFUL-PCE-CAPABILITY TLV 的第 20 位声明 COLOR-CAPABILITY；随后，LSP 对象可携带类型为 67、长度为 4 的 COLOR TLV。未声明该能力的对端不得接收这种编码，同一 LSP 对象中的重复颜色只处理第一个。这些规则让“对端支持什么、消息是否合格”成为可检查的事实，却没有让“服务因此获得低时延”成为事实。

当 SR 策略关联同时出现时，RFC 的克制更明显。对于 RFC 9862 所描述的 SR Policy Association，颜色已经在关联标识中编码；LSP 对象中的 COLOR TLV 不应再承担该任务，关联中的颜色具有优先权。优先级只消除了某个协议对象的歧义。它不替运营商选择业务分类，也不命令任何设备把流量送入这条策略。

PCC 的拒绝也不应被读成整个业务链的判决。如果 PCC 无法遵守收到的颜色，必须返回 Invalid Color；同一保护关联组中的颜色不一致，也必须返回 Inconsistent Color。这些响应精确地记录了一个控制面输入被拒绝的原因。反过来，接受一个输入也只说明该输入穿过了这个协议门槛。随后仍有本地配置、路径对象、业务映射、转发表、数据面与性能观察等独立层次。

RFC 9863 没有把这些层次藏起来。它明确将服务如何映射到有颜色的路径、颜色的其他用途和部署影响留在范围之外。它要求实现可允许运营者打开或关闭能力、配置颜色分配，并指出 PCC 可以有自己的本地策略；它只说运营者可以读取 TE 路径状态以核对“预期颜色”，没有添加新的存活性监控。一个读回的标签因而是标签读回，不是服务验收。

这正是可审计自动化需要保留的间隔。报告应逐项保存：能力声明、消息中的颜色来源、PCC 的接受或拒绝、当地策略版本、路径的运行状态、服务映射决策和独立性能测量。把这些收缩成绿色的“低时延”徽章，会让可见的字段替代尚未验证的效果。

Heng Lu 对运行代码的强调也适用于这里。共同的字段定义能帮助独立参与者协调，却不能凭发布而创造未被采用的运行事实。颜色值是协调工件；由谁定义本地语义、是否采用、是否映射服务以及是否接受结果，仍在运行系统和负责该系统的人手中。RFC 9863 的价值正在于它没有假装这些后续决定已经发生。

来源