摘要

  • 现行 MPLS STAMP 草案要求 LSP 或伪线两端各自配置会话与报文终止机制，并把 STAMP 专用的 VCCV 信令扩展留在范围之外。
  • 成功回包能证明一个有边界的协议交换，却不能充当两端对业务对象、工作模式、时钟依据和决策用途达成一致的持久凭证。

draft-ietf-mpls-stamp-pw-21 中最值得治理者注意的，不是报文图里的某一位，而是架构说明里的三句话。第一，终止 STAMP 测试报文的机制在 LSP 或伪线两端本地配置。第二，伪线上的 STAMP 专用 VCCV 控制信道扩展不在本文范围内。第三，VCCV 控制信道信令只为伪线定义，没有为 LSP 定义，因此 LSP 目前只能依靠本地配置。

这并不意味着草案设计有缺陷。测量协议没有必要把客户名称、内部审批、告警阈值和合同责任都塞进报文。把共同规范保持在最小范围，通常更利于互通。问题在于：本地保留的那些信息不会因为报文成功往返，就自动形成一份可审计的两端合意。

SSID 是索引，不是配置副本

RFC 8762 把 STAMP 会话定义为一个发送端与一个反射端在一段时间内形成的双向报文流，同时明确把配置和管理方式留在协议范围之外。设备可以通过命令行、OSS/BSS、SNMP 或 NETCONF/YANG 控制器接受配置。反射端随后按照本地状态工作，可以有状态或无状态，也可以采用认证或非认证模式。

RFC 8972 引入 STAMP 会话标识符 SSID。支持该标识符的反射端必须在测试开始前具备识别会话所需的全部元素；不匹配的测试报文应被丢弃。至于这些元素怎样下发，规范仍然不作规定。MPLS 草案进一步要求 SSID 非零，并在两个方向都携带它。

Format-1 保留 IP/UDP 头。端点用相应地址、目的 UDP 端口、SSID 和本地参数共同识别会话。Format-2 不携带 IP/UDP 头，因而必须把 SSID 与正向或反向 LSP/伪线上下文以及本地参数结合起来。报文中的标识符由此成为一把查找本地记录的钥匙，而不是那份记录的完整内容。

同一把钥匙能在两端打开记录，并不证明记录的语义完全相同。一端可能把会话绑定到某条客户伪线，另一端却把它归入底层传送网的维护任务；两端也可能在反射模式、认证状态、TLV 集合、测试速率、时钟源或告警阈值上使用不同版本。现有来源没有证明现实部署中发生了这些偏差。它们揭示的是更窄、也更可靠的事实：报文无法独自排除这种偏差。

VCCV 已有协商，但只协商自己的对象

说伪线完全没有线上协商同样不准确。RFC 5085 定义了 VCCV 控制信道类型和连通性验证类型的能力通告。两个 PE 交换支持的组合，选择共同类型，并在伪线重新发信令之前持续使用。RFC 7708 又为不使用控制字的情形加入基于 GAL 的 Type 4，并规定多个类型同时可用时的选择次序。

MPLS STAMP 草案复用这些机制，把测试报文从普通转发路径中截出，交给端点控制面处理。每个会话必须有且只有一种截出机制生效。草案还特意拆开两个容易混淆的动作：截出机制决定报文停止普通转发；随后出现的 G-ACh 类型负责识别其后是带 IP/UDP 的 Format-1，还是直接承载 STAMP 的 Format-2。

因此，VCCV 选择是一项真实证据：它可以说明两端找到了一种共同控制信道能力。但它没有协商完整的 STAMP 会话语义，包括 SSID 策略、具体路径上下文、地址端口、认证与状态模式、TLV、包长、速率、时钟来源、业务归属和允许的下游用途。这些仍然依靠本地配置与范围外的管理系统。

正确的结论不是“线上什么都没谈”，而是“线上每一层只谈自己的对象”。治理失真发生在运维系统把 VCCV 能力一致、STAMP 成功回包和业务标签正确，压缩成一个没有来源边界的绿色状态时。

一次成功回包究竟证明什么

如果发送端收到格式正确、SSID 符合预期的响应，它已经获得有价值的证据：报文离开发送端，经过一个可用的转发上下文，在远端被正确截出并识别，又在足够兼容的状态下返回。根据工作模式与验证结果，这个交换可以支持时延、时延变化或丢包计算。

它没有说明谁批准了两端配置，也没有给出两端的配置代次。它不能证明双方把该会话关联到同一业务、同一排障目标或同一 SLA。它也不证明两个时钟处于共同接受的精度范围，测试流量符合约定预算，MTU 余量已经验证，或者某次单边变更没有让旧有业务标签失效。

草案新近明确的“单一网络管理域”并不会补出这些证据。一个管理域内部照样可能存在多个团队、控制器、厂商设备、变更窗口与日志系统。行政边界可以说明谁拥有最终控制权，却不能替代两端配置之间的事务一致性。

这里需要的是证据分层，而不是否定测量。回包证明回包；配置一致需要配置证据；时钟可信需要时间源证据；服务达标还需要业务定义和接受规则。只要每一层不借用另一层的权威，STAMP 结果就能在其真实范围内发挥作用。

建立两端测量配置凭证

缺失的治理对象可以很小。一份两端测量配置凭证先绑定发送端和反射端身份、管理域、LSP 或伪线及方向、截出机制、STAMP 报文格式、G-ACh 类型与 SSID。对 Format-1，还要记录地址与端口；对 Format-2，则记录两端用于识别会话的正反向路径上下文。

第二部分保存测量语义：反射端是有状态还是无状态，报文采用认证还是非认证模式，允许哪些 TLV，使用何种时钟源及同步证据，包长与 MTU 余量，发送速率，反向容量预算，关联业务、观测目标，以及哪些决策可以依赖该结果。这些字段不必逐包上网，却必须共享一个不可混淆的身份。

两端各自提交配置哈希或不可覆写的版本引用。凭证注明下发每一侧状态的控制器或操作员、接受这一组合的复核人、兼容性测试、有效期和回退权限。一端发生变化时，应生成新凭证，而不是让新的本地状态默默继承旧组合的认可。

凭证还应明确证据等级。“VCCV 能力已选定”不等于“STAMP 参数完全一致”；“收到响应”不等于“时钟符合政策”；“算出指标”不等于“客户业务达到目标”。下游系统只能使用已经完成的那一级，不得自动升级。

这份凭证是 Daniel Kade 的治理建议，不是 IETF 新字段、注册表或一致性要求。它的意义恰恰在于把组织事实留在本地，同时不让这些事实从审计链中消失。

最难发现的是部分一致

完全不一致往往比较显眼：反射端无法识别会话，报文被丢弃。真正危险的是只一致到“足以回包”。

例如，反射端从有状态切换为无状态后仍可能响应，但可推导的丢包方向发生变化；认证模式变化会改变结果可承载的信任；路径重绑定可能保留 SSID，却已经不再对应面板上的原业务；时钟进入保持状态后仍能输出整齐时间戳，但不确定度可能超过决策门槛。

这些是用于检验控制设计的情形，不是对任何实现或运营商的事实指控。来源中没有故障记录、厂商缺陷或部署普及度数据。它们只说明一个不可回避的逻辑边界：成功报文不是完整配置的指纹。

来源

  1. MPLS STAMP 草案状态、变更历史与 Datatracker API 记录
  2. 第 21 版 HTML、纯文本、XML与第 20—21 版对比
  3. IESG 表决记录、文档负责人说明与 MPLS 工作组
  4. RFC 8762 与 RFC 8972
  5. RFC 5085、RFC 7708与 RFC 5586
  6. RFC 7799、Minimum Initial Specification与 The Policy Mirror