摘要

  • RFC 2214 在每个接口上公开 backlog C、delay D、slack 与 RowStatus，四个对象都是 read-create。
  • 这些值记录的是实现相对流体服务的偏差和本地资源选择；它们不证明某条流经过该接口、持续保有 reservation、取得完整的 RFC 2212 界限或满足实测延迟。

一行管理数据很容易长成一份“保证书”。接口有明确索引，Backlog 用字节表示，Delay 用微秒表示，Slack 是一个可用余量，Status 还显示这一行是否有效。更诱人的是，四列都被 RFC 2214 声明为 read-create。管理者不只可以看，原则上还可以写。

但 RFC 2214 的价值，恰恰在于它没有允许这行数据越界。

这份由 Fred Baker、John Krawczyk 与 Arun Sastry 编写、1997 年 9 月发布的标准，不负责定义 Guaranteed Service 的全部数学保证。那是 RFC 2212 的工作。RFC 2214 做的是另一件事：把真实网络设备偏离理想模型的方式，以及设备如何利用剩余延迟空间节省资源，投影到 SNMP 管理面。

C 不是队列当前有多长

intSrvGuaranteedIfBacklog 以字节记录 C。RFC 2214 把它描述为具体实现偏离严格 bit-by-bit service 时产生的数据积压。对于 packetized weighted fair queueing，标准举例说可以把它设为最大包长。

在 RFC 2212 中，C 是与速率相关的误差项。计算延迟界限时，C 要除以 reservation rate R。这个形式承认：某些实现成本会随着传输速率变化，例如把 datagram 串行化所需的时间。

“字节”这个单位很容易制造误读。Backlog 对象不是 SNMP 查询发生那一刻的实时排队深度。它不是在回答“现在有多少字节等待发送”，而是在回答“这类实现偏差应当以多大的速率相关误差进入模型”。单位相同，不代表证据相同。

D 不是一次包传输测量

intSrvGuaranteedIfDelay 以微秒记录 D。D 是每个 service element 上与速率无关的最坏传输时间变化。RFC 2214 举出的例子包括：datagram 从输入接口到处理器，再从处理器到输出接口的最坏时间；以及 Ethernet 遭遇最大碰撞次数时的延迟。

这个值通常来自启动或配置，不是某个包的时间戳。要形成端到端界限，各跳的 C、D 还必须沿真实路径合成为 Ctot、Dtot。RFC 2212 明确把收集这些 per-hop 值的机制留给 reservation setup、routing 或其他 management function。

保证本身还有前提：流量必须符合 TSpec，网络组件不能失效，流存在期间路径不能改变。Guaranteed Service 控制的是最大排队延迟，不是最小延迟或平均延迟；要得到 datagram 的最大总延迟，还必须加入 path latency。

所以，从接口读出 D，只能证明这个接口声明了一个本地参数。它不能证明某条流确实经过这里，也不能证明其他跳的值正确、合成过程完整或路径保持不变。

Slack 保存的不是余量，而是一次选择

第三个对象揭示了本地资源取舍。若 network element 为 flow i 消耗 Si 的 slack，从而减少为该流保留的资源，RFC 2214 要求设备把 Si 存下来。之后同一流的 reservation refresh 到来时，设备必须直接复用同一个 Si，不再重新计算。标准把理由写得很清楚：保持 reservation process 的一致性。

示例中的总余量为 S = Dreq - (b/r + Ctot/r + Dtot)。中间设备可以消耗 s <= S。RCSD scheduler 可以把本地 delay bound 从 d 增加到 d+s；WFQ scheduler 可以按照转换规则降低本地 reservation rate，同时不增加预计的整体端到端界限。

因此，slack 不是“闲置带宽”，也不是“测得的额外延迟”。它是可支配的延迟预算，更是设备已经如何支配这份预算的记录。若每次 refresh 都重新选择，完全相同的请求可能不断得到不同的本地资源承诺。保存 Si，是在阻止这种漂移。

问题在于，RFC 2214 的表以 ifIndex 为索引。它本身不保存完整的 flow identity，也不保存 RSVP 的 PATH/RESV 轨迹和 refresh 历史。通用 flow table 属于 RFC 2213，RSVP 的 receiver-oriented soft state 属于 RFC 2205。要证明 slack 被一致复用，必须把这些层次重新连起来。

可写参数证明了控制权，不证明结果

四个对象都是 read-create，意味着管理面可能改变它们。RFC 2214 的 Security Considerations 直接指出：SNMP SET 可以按照不同于 RSVP negotiation 的规则，产生 RSVP 或 Integrated Services reservation。

这句话切断了最常见的推断。SET 成功，不等于接收方通过 RSVP 表达了同意；也不等于 soft state 仍被 refresh 维持、admission control 接受了正确主体、classifier 匹配了预期包，或 scheduler 兑现了预期处理。

Status 也没有补齐证据链。RFC 2214 只说它在配置为 Guaranteed Service 的接口上有效。RowStatus 的通用语义中，active 表示 conceptual row 可供 managed device 使用。它是关于管理行的本地状态，不是关于端到端路径的结论。

RFC 2214 留下的历史意义，不是一张自证其真的保证表，而是一套更诚实的账本。C 记录速率相关的实现误差，D 记录与速率无关的本地延迟，slack 记录延迟预算与资源承诺之间的选择，Status 管理这行数据的生命。账本能描述接口声明了什么、设备选择了什么；真正的服务结果仍需由流、路径、合成、流量合规与运行观测共同证明。

来源