摘要

  • RFC 2215 把单个网络元素的本地值，与沿路径逐步合成的值明确分开；参数在概念上属于“下一跳”，不是设备的永久属性。
  • 它没有发明一个万能聚合函数：能力断点取 OR，IS-aware 节点数递增，可用带宽与路径 MTU 取最小值，最低路径时延作有上限的求和。
  • 组合结果只是带条件的路径刻画。它不等于资源预留、准入结果、实际性能、数据包送达或应用成功。

路径不是一列可以求平均的数

假设一份路径描述到达下一台路由器。里面有四个问题：之前是否出现过不支持相应服务的环节？已有多少个理解 Integrated Services 的节点参与？最窄的可用带宽是多少？传播与处理所需的最低时延累计了多少？

这四个问题看似都在描述“同一条路径”，实际却对应四种逻辑。只要有一个断点，断点就成立；节点数应当加一；瓶颈只能由最小值决定；时延贡献必须累加。RFC 2215 的价值，正是没有让统一格式掩盖这些不同的证据语义。

它讨论的是 characterization，而不是已交付的服务。参数可以帮助应用或其他节点决定是否提出 QoS 请求，但当参数开始沿路径传播时，某个具体预留甚至还没有发生。把这份描述读成服务承诺，就会把“可供决策的先验信息”偷换成“已经执行的结果”。

本地事实和路径结论必须分开

每个特征参数都有本地值与组合值。本地值来自一个网络元素；组合值则把此前路径的结果与当前元素的值按指定规则合并，再交给下一跳。合成可以朝接收端进行，也可以朝发送端进行，因此方向也是 provenance 的一部分。

RFC 2215 强调参数在概念上是 per-next-hop。共享介质或大型云状子网可能面对多个出口，不同下一跳的带宽、时延或 MTU 并不相同。只有当差异处于公开容差内，设备才适合用一个共同值代替。

本地值与组合值使用不同 ID，使管理系统可以在中途看到“本节点说了什么”和“到这里为止路径如何”。一旦只保存最终数值，很多信息不可逆地消失：最小值不知道瓶颈在哪，求和不知道谁贡献了多少，OR 标志也不指出断点位置。

默认值不是普遍真理

通用参数在不同服务中含义相同，但取值未必相同。service number 1 表示全局或默认分支；某项具体服务可以提供 override。

组合规则会保留这个分叉。服务专用值到达本节点时，优先与本服务的专用值合成；若本节点没有专用值，才使用本节点的全局值，但结果仍属于该服务。全局值到达一个拥有 override 的节点时，系统会新建服务专用分支，同时继续维护全局分支。

RFC 给出的例子很直观：普通转发可能支持 1500 字节 MTU，而某个 Guaranteed Service 实现由于调度器或硬件限制，只能支持 250 字节。后者不是对物理路径的重新命名，而是一条更窄的可执行边界。把两个分支压成一个数，要么欺骗服务用户，要么错误限制普通流量。

断点一旦出现，后面无法抵消

NON_IS_HOP 的本地值表示当前元素不支持相关 QoS 服务，或已知服务链出现断点。组合规则是逻辑 OR。前面任何位置出现一次 true，后续节点无论多完整，结果都保持 true。

这一规则不允许后来者替历史补票。一个隧道之后连续五台支持 QoS 的路由器，不能让隧道内部自动获得能力。规范要求保守推断：除非入口或信令协议能证明隧道内部支持相应控制，否则必须按断点处理。

麻烦在于，真正不懂本规范的设备也不会主动设置这个标志。发现责任可能落在邻接节点、信令协议或人工配置上。所以 break bit 不是“不支持设备的自证”，而是证据链对缺口的保守声明。

全局断点还会污染其他参数：接收者应把本规范中的其他路径值视为可能不准确；服务专用断点则削弱该服务的其他值。RFC 2210 负责说明 RSVP ADSPEC 如何携带它，但承载成功并不会消除警告本身。

节点数只统计能参与统计的节点

NUMBER_OF_IS_HOPS 每经过一个 IS-aware 元素就加一。它回答“有多少个已知参与者”，不回答“整条路径总共有多少个环节”。

因此计数必须与断点标志一起读。一个不理解 Integrated Services 的设备不会给 aware-hop counter 加一。五个已计数节点和“路径只有五跳”不是同一个命题。RFC 2215 由此拒绝了一个常见偷换：没被记录，不等于不存在。

带宽取最小值，但输入只是事前估计

可用带宽的本地值需要综合物理资源、管理限制和策略控制，组合时取最小值。最终结果说明哪一段“所报告的可用量”最小，却不保留瓶颈位置，也不等于带宽已经被分配。

规范明确承认估计的局限。参数必须在具体 QoS 请求之前给出，此时目的地、服务类型和预留策略可能尚不清楚；设备可以尽力估计，甚至允许结果显著高于后来真正可用的带宽。服务若只能使用总容量的一部分，可以另给更小的 override。

零不是零带宽，而是未知。当元素不能或不愿给出估计时，可以输出 0；接收者必须认为真实可用带宽未知。由于组合函数是 MIN，0 会一路保留。后面再大的数也无法把“缺少证据”改写成“有资源”。

最低时延累加，但会饱和为不确定

最低时延只包括传播与处理造成的最小可能延迟，不包括可变排队时延。它可以作为 RFC 2212 等服务计算的基线，却不是日常观测到的 RTT，也不是 Guaranteed Service 的 C/R + D 上界。

大型云或多播路径可能有多个最低时延。理想做法是按下一跳分别报告；若只能给共同值，应取所有可能路径中最小的那个，因此很可能低估真实路由。也可以直接报告 indeterminate。

组合值按微秒相加，并以 (2**32)-1 为上限。这个最大值不是一个巨大而精确的时延，而是“不确定”。它可能来自某个元素无法预测，也可能来自求和溢出。一旦出现，后续组合继续保留该值。精度要求同样是证据规则：如果每一跳都粗糙地向上取整到毫秒，多跳累加会制造规范不允许的虚假时延。

MTU 同样取最小值，却要求输入正确

路径 MTU 的本地值是该元素无需分片即可承载的最大 IP 包，包含 IP 与上层协议头，不包含链路层头。沿路径取最小值后，得到所选路径与服务分支的上限。

它和带宽虽然同为 MIN，证据质量不同：每个 IS-aware 元素必须提供正确有效的 MTU。服务专用 override 可以降低全局 MTU，却不能提高它。该限制防止服务声称自己能承载超过底层设备能力的数据包。

即便如此，组合 MTU 也不是送达收据。路径会变化，隧道可能未被正确描述，发送端未必使用该大小，数据包还可能因其他原因失败。最小值只回答它被设计回答的问题。

同一份 RFC 还放着一个“不参与组合”的对象

参数 127 是 TOKEN_BUCKET_TSPEC。它描述速率、桶深、峰值速率、最小计费单元和最大包长，但中间节点不会为它导出本地值并沿路径合成。它是共同使用的流量契约结构，不是第五种路径刻画算法。

这种并置再次提醒读者：数据结构处在同一套架构中，不代表证据角色相同。TSpec 说明允许或预期的流量，不证明实际流量合规，更不证明准入、转发或结果。

组合值处在事实链的中间

RFC 1633 讲架构，RFC 2205 讲 RSVP，RFC 2211 与 RFC 2212 讲具体服务，RFC 2216 讲服务规范模板。RFC 2215 则限定共同参数如何形成路径声明。

一份可审计记录至少应分别保留：参数 ID；全局或服务分支；方向与路径 epoch；本地值的来源和计算方法；前一个组合值；组合函数；断点或不确定状态；QoS 请求；逐元素准入；实际安装状态；流量观测；交付与应用结果。格式正确的路径对象不能替后面的系统出具事实。

来源与限制

主来源是 RFC 2215，状态由 RFC Editor 和 IETF Datatracker 记录。RFC 2815 展示了后来在 IEEE 802 网络中的映射：MTU 与 break 信息必须准确，而可用带宽可以是很宽松的估计。这些资料证明规范语义与文献关系，不证明今天的普遍部署、特定厂商实现、实时预留、实际性能或事故。

Heng Lu 关于运行代码优先、最小共同规则与本地决策以及现实层与符号层的文章提供编辑视角：声明可以指导行动，但执行事实仍需实现与观测。这是公开说明的分析框架，不是对 1997 年设计因果史的主张。