摘要

  • RFC 2213 把接口可保留能力和活动保留流投影到 SNMPv2 MIB，公开选择器、速率、突发、队列元数据、policing、丢弃策略与 RowStatus。
  • 它同时限定每个字段的权威：流号只用于 SNMP 索引，owner 只是安装进程类别，计数器从安装时起算，队列含义依实现而异，SNMP SET 也可能绕开 RSVP 的谈判规则建立保留。

intSrvFlowOwner 只有三个值：other、rsvp 和 management。定义很精确——它标记把这条流安装进 queue policy database 的进程。它没有保存人的名字、组织、credential、授权决定，也没有保存原始请求。

因此，owner 显示 rsvp，最多说明这条管理记录把安装来源归为 RSVP。它不证明哪个接收者发起请求，不证明 policy data 被谁审查，不证明 admission control 为什么接受，更不证明 soft state 此刻仍在刷新。字段名看似接近“所有者”，语义却只是一种进程分类。

管理面终于看见了保留流

Fred Baker、John Krawczyk 与 Arun Sastry 在 1997 年 9 月发布 RFC 2213。它为 Integrated Services 定义了 SMIv2 MIB：一张接口表记录已分配和最大可分配带宽、buffer、flow 数量、额外传播延迟与状态；一张 flow 表列出系统接口上的活动保留流。

每个 flow row 汇集 session type、owner、源和目的选择器、协议与端口、接口、速率、突发、weight、queue、最小与最大报文尺寸、best-effort 与 policed 计数、丢弃政策、QoS service、分类顺序和 RowStatus。许多对象被定义为 read-create，意味着管理者可能不仅观察，还能创建或修改局部控制状态。

但 compliance 又允许不少对象只实现为只读。MIB 描述的是标准化可能性，不是对所有设备写能力的担保。

SessionNumber 只是表格地址

intSrvFlowNumber 使用 SessionNumber 类型，RFC 却明确写明：它只用于 SNMP indexing，与任何 protocol value 都没有关系。这个数字不能被当成 RSVP SESSION、应用会话、客户身份或跨节点关联键。

创建新行时，intSrvFlowNewIndex 用 TestAndIncr 避免索引冲突。管理者先读出候选值，在 SET 中原样写回；若收到 inconsistentValue 就重试。它解决的是并发创建时“谁拿到这个表格位置”，不是“现实中这条业务流是谁”。

地址、mask length、协议、端口和接口描述本地 classifier 应怎样识别流。若行已 active，多项选择器不能改变。这种冻结保护行的一致性，却不能证明真实 packet 曾经命中，也不能证明后续每一跳拥有兼容状态。

可移植的字段名，不等于可移植的行为

保留速率有明确来源：Controlled-Load 取自 Tspec rate，Guaranteed Service 取自 Rspec clearing rate。burst 表示预期最大突发，但网络是否提供额外 pacing 仍属可选。MinTU 与 MaxTU 规定 policing 怎样解释报文尺寸，不是观测到的流量统计。

weight 与 queue 更局部。RFC 2213 特别说明，两者含义都取决于实现，因为设备使用不同的权重程序和队列编号。两台路由器上相同的“7”可能完全不同。配置值不能单独证明实际 scheduler、拥塞、延迟或包的处理结果。

intSrvFlowPoliced 的时间边界同样关键。flow row 的说明说它从 flow installation 开始计数；对象本身统计从该 flow service inception 起被 policing 的 packet。删除并重建一行，就开启新的计数 epoch。数值上升只证明本地 agent 按自身规则递增了对象，不证明所有其他包合规，也不证明交付。

intSrvFlowBestEffort 记录被降为 best effort 的包；intSrvFlowDiscard 决定被 policing 的流量是丢弃还是转入 best effort，默认是后者。政策存在，不等于某个包经历了这条路径。

active 只证明管理生命周期的一步

intSrvFlowStatus 对活动流为 active，并可用于安装、删除或授权静态 classifier 信息。RowStatus 表示 row 已可供 managed device 使用，却不是产生该状态的审计记录。

RFC 2213 的 Security Considerations 给出了最清楚的警告：SNMP SET 可以按不同于 RSVP negotiation 的规则产生 RSVP 或 Integrated Services reservation。一次成功 SET 不能改写成接收者同意。一个 active row 也不能证明 refresh 仍持续、policy control 已认可主体、classifier 正在命中、scheduler 正按预期运行，或整条路径提供了同一服务。

RFC 2205 甚至把 RSVP confirmation 也只称为高概率指示，而非直到 sender 的服务保证。本地 MIB 行的结论只能更窄。

RFC 2213 的历史意义在于，它让隐藏的控制面状态变得可查、可比和有时可写。它最现代的教训也是同一件事：管理记录越详细，越需要保留“它究竟证明到哪一步”的边界。

来源